Browser Extension Privilege Abuse in Bug Bounty Programs
Extensions sit closer to the browser than most web apps. A weak content script or a loud permission set can outrank a solid CSP on the site itself. When a program includes its Chrome or Firefox add-on, treat it as a privileged client—not a cosmetic toolbar.
Start with the manifest
Read manifest.json (V2 or V3) before clicking around. Note permissions, host_permissions, optional_permissions, web_accessible_resources, and background service worker entry points. Broad <all_urls> plus unconstrained tabs or webRequest raises the ceiling for impact stories, but you still need a concrete bug.
Look for:
- Content scripts injected on login and billing origins
- Message listeners that accept events from any sender
- WAR entries that expose HTML/JS under extension IDs
- Native messaging hosts if declared
Firefox and Chrome differ on some APIs; test the store build the program ships. Unpacked developer builds are fine for iteration when the policy allows, but final impact should reference the distributed package when versions differ.
Message passing is the classic footgun
Background pages often do privileged work when a content script says so. If chrome.runtime.onMessage skips sender.id / sender.url checks, an attacker page—or another extension—may trigger cookie reads, token exports, or tab navigation.
Proof pattern: from a page you control that the content script cannot normally reach, or via XSS on an in-scope site that can postMessage into the extension page, call the privileged action and show a canary effect (read a test token, open a tab to your canary URL, write to storage.local).
XSS inside an extension page is especially ugly because extension origin privileges apply. Sink-hunt options pages and popup UIs that reflect query params or storage values. Externally connectable configurations deserve a dedicated pass—externally_connectable mistakes turn random HTTPS origins into remote controllers.
Web-accessible resources and UXSS-adjacent tricks
If sensitive scripts are listed in web_accessible_resources, a web page might load them in a surprising context. Combine with path confusion or open redirects in the extension origin. Also check whether the extension inserts DOM into HTTPS pages using innerHTML with data from the network.
Auth tokens in storage.local without device binding show up often. An extension XSS or message abuse that exfils that store is a clean report when the token works on the API.
Stay inside program rules
Do not mass-update other users' extensions or push store malware. Use sideloaded developer builds when allowed, your own accounts, and canaries. State browser version and extension version.
Recommend least-privilege host permissions, strict sender checks, avoiding WAR for privileged code, and sanitizing any HTML the popup renders. Extension bounty hits hard when you show the bridge from untrusted web content to privileged APIs—keep the bridge diagram short and the proof reproducible.
If optional permissions are requested at runtime, test the denied state too. Some extensions fail open and keep privileged messaging while the UI claims the permission was refused.
Store listing screenshots and privacy policies sometimes overclaim isolation. When behavior contradicts the listing, mention that gap—it helps triage prioritize.