Extension Permissions
HTTP telemetry and hard-coded API keys in popular Chrome extensions
Symantec highlighted extensions that sent data over plain HTTP or shipped secrets in client-side code—what leaks, why Wi‑Fi matters, and what developers should do instead.
Symantec researchers, including Yuanjing Guo, published findings that several widely installed Chrome extensions either transmitted data over unencrypted HTTP or embedded API keys and tokens directly in extension JavaScript. The work is a reminder that popularity and brand names do not guarantee transport security or secret hygiene.
Plain HTTP: what can go wrong
When an extension calls home over HTTP, anyone on the same network path—think public Wi‑Fi, compromised routers, or adversary-in-the-middle setups—can observe or in some cases alter traffic.
Reporting described leaks such as visited domains, machine identifiers, OS details, usage analytics, and even uninstall events, depending on the product. None of that needs to be passwords to be useful for profiling or follow-on social engineering.
Examples cited in coverage included SEO / rank-style add-ons calling Trellian hosts over HTTP, Browsec VPN hitting an S3 website over HTTP on uninstall, MSN new-tab style extensions sending identifiers to ceipmsn endpoints over HTTP, and a password-manager class product using HTTP for stats—which does not imply vault passwords left the wire, but undermines confidence in how seriously encryption is applied elsewhere.
Hard-coded secrets in the bundle
A separate bucket was credentials in shipped code: Google Analytics 4 measurement secrets, Azure speech keys, AWS keys for screenshot upload, telemetry keys, third-party SDK keys (e.g. InboxSDK in Antidote Connector, with Symantec noting many other extensions inherit the same library pattern), GIF API keys, on-ramp / Web3 partner keys, and geolocation API keys.
Impact models vary: spam analytics endpoints, burn cloud budgets, upload junk to someone else’s bucket, or spoof partner traffic. Severity depends on how each vendor scoped and rotated keys; some vendors responded to press that specific keys were limited, rate-capped, or non-secret identifiers—worth reading in original advisories, not second-hand.
The structural lesson from researchers: client-side extension code is not a vault. Anything in the CRX can be extracted.
What developers should do
- HTTPS everywhere for any telemetry, config, or uninstall beacons.
- No long-lived secrets in packaged JS—use a backend broker, short-lived tokens, and rotation.
- Audit third-party SDKs for bundled keys shared across many extensions.
What users should do
- Prefer extensions that minimize data collection and document it clearly.
- Treat HTTP-only callouts as a yellow flag until the vendor patches.
- On untrusted networks, assume metadata leaks are easy—VPN or tethering reduces local sniffing risk but does not fix bad extension code.
Practical next step
Revisit chrome://extensions and update everything; check release notes or vendor blogs if you rely on any product named in the research. eSafe can help you see permissions and risk signals in one place.
Go deeper
Browser extension permissions explained → — how capabilities and network access fit together on install prompts.
Report: The Hacker News.
FAQ
- Why is HTTP a problem if the data seems low sensitivity?
- On untrusted networks, passive observers can read unencrypted HTTP. Metadata, identifiers, and payloads that grow over time still raise compliance and account-risk concerns.
- Why can’t API keys in extension JavaScript stay secret?
- Packaged extension code is inspectable. Anything embedded for client-side use can be extracted; servers should hold real secrets and issue short-lived tokens instead.
- What should developers do instead?
- Enforce HTTPS for all telemetry, move secrets to backend services, use per-install OAuth where appropriate, and minimize data collection to what is strictly necessary.
Related browser risks
- Network requestsHost permissions, fetch, declarativeNetRequest, redirects, documented abuse at reported scale, and mitigations.
- Network filteringChrome extension declarativeNetRequest (DNR): block & redirect requests, MV3 rule caps, phishing via tampered lists—permission & update c…
- All-sites accessPlain-language deep dive on host permissions that cover every website: capabilities, real abuse cases, Chrome/Mozilla documentation, and …
Scan your extensions to see if this permission is active on your profile—clear labels, no guesswork.