How to Audit Browser Extensions for Hidden Data Collection

Here’s an awkward question, just for you. Do you really know, at this very second that you are reading this, what every single one of the apps added to your internet browser is actually doing on your machine? This is never just theoretical scare. Threat research experts discovered a widespread series of over 100 malicious Chrome extensions with over 20,000 installs that stole data via G Suite and Telegram interactions. In this tutorial, we’ll learn to audit browser extensions to identify data theft. Remember, not every extension is malicious. But some need to be identified. Let's get started!

For well-known and popular extensions, such audits are not required, as developers from all over the world already audit and scan their code to ensure safety and security for the users.

If you are tech-savvy or a budding security analyst, this guide will help you check broswer extensions for security issues. Let's get started and master the process of browser extension audit.

Why This Is a Bigger Deal Than People Realize

Once an extension is installed, it becomes part of the web browser. Depending on the permissions an extension seeks, it can:

Modify and read every web page you've visited
Access your search and browsing history
Read cookies, which include access to session tokens. These tokens keep you logged in
Capture web form inputs, including text in browser search bars and URL address fields
Intercept and reroute key network requests
Run in the background in inactive state too

Got an idea of the amount of information an extension can potentially harvest?

How Extensions Actually Access Your Data

Every browser extension comes with a file called manifest.json, which is like an identification card. It tells the browser what it is allowed to do. And, web browsers like Chrome, Edge, or Firefox check it and enforce the rules.

From a privacy audit's perspective, these three things in that file matter:

1. Permissions

This governs what browser features can be accessed by the extension, e.g., cookies, history, tabs, storage, or webRequest. Some of these are normal or low-risk, while others can be alarming or very serious.

2. Host Permissions

Next comes host_permissions (or the older permissions array in Manifest V2) that governs which websites the extension can access and interact with. Here, the <all_urls> entry denotes that the extension can read and modify content on every website the user visits.

3. Background Scripts and Content Scripts

Background scripts/service workers: These run independently without any visible tab or visible action. They may run continuously while the browser is open. These scripts can be used to silently collect data without user consent.
Content scripts: These scripts can be injected directly into the web pages you visit. This essentially means the extension can access whatever is rendered on screen; that includes page text you may type in the web forms.

Here’s a sample manifest that may alarm any aware user:

{
  "manifest_version": 3,
  "name": "Super Handy Toolbar",
  "permissions": ["cookies", "history", "tabs", "storage", "webRequest"],
  "host_permissions": ["<all_urls>"],
  "background": {
    "service_worker": "background.js"
  },
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["content.js"],
      "run_at": "document_start"
    }
  ]
}

Take a look at what features this extension wants access to:

Cookies, which can be used for session hijacking.
Complete browsing history to spy on your activities.
Access to every open tab for god knows what!
Ability to intercept network requests to essentially control the traffic.
And finally, unrestricted access to every website you visit.

So, this sample extension manifest has serious issues when it comes to users' privacy and safety.

Manifest V2 vs. Manifest V3: What Changed for Data Collection

Aspect	Manifest V2 (legacy)	Manifest V3 (current standard)
Background execution	Persistent background page, can run indefinitely	Service worker, browser can terminate it when idle
Network interception	Blocking `webRequest`, can inspect/modify traffic live	`declarativeNetRequest`, rule-based and more restricted
Remote code execution	Extensions could fetch and run remote JavaScript	Remote code execution is disallowed; code must ship with the extension
Host access declaration	Bundled into a single `permissions` array	Split out into `host_permissions` for easy auditing
Chrome Web Store status (mid-2026)	Being fully phased out, final listings removed August 31, 2026	Required for all new and updated extensions

In most cases, with a few exceptions, if a developer is hesitating to upgrade to Manifest V3, this alone makes the extension a good candidate for an audit.

The Extension Audit Framework: A Step-by-Step Process

This is the core of the audit process. Whether you are auditing a new extension you are going to install for the first time, or auditing an old one you are using for the last 5 years, follow this process as it is without any deviation.

Step 1: Build a Full Inventory

Unless you know what you have to audit, you can't start this process. To get a list of extensions on your browser:

Chrome / Edge / Brave: Go to the chrome://extensions or edge://extensions page.
Firefox: Go to the about:addons page.

📷 Get the extension details along with its ID

Make sure you turn on Developer Mode in Chrome-based browsers. It ensures the extension IDs and some additional extension details are displayed, which you’ll need later.

Write down (in a text file or on paper ) the names and IDs of all the installed extensions.

Step 2: Read the Permissions Like a Skeptic

Go to each extension’s details page and carefully read the permissions it currently has. Now, for each permission, ask yourself: does this extension actually need this to function?

Here’s a simple risk assessment table to help you decide for every permission:

Permission	What it allows	Risk level	Legitimate use case
`activeTab`	Access to the current tab, only when you click the extension	Low	Screenshot tools, one-click utilities
`storage`	Local data storage within the browser	Low	Saving settings, preferences
`tabs`	Reading URLs and titles of all open tabs	Medium	Tab managers, session savers
`cookies`	Reading and writing cookies	High	Rarely needed outside of dev tools or password managers
`history`	Full browsing history access	High	Only justified in history-management tools
`webRequest` / `declarativeNetRequest`	Intercepting or modifying network traffic	High	Ad blockers, privacy tools
`<all_urls>`	Read/modify content on every website	Very High	Ad blockers, translators, password managers. If anything else, question it!

If a password manager needs <all_urls> permission, it makes sense because it has to detect login forms on every web page. But if a simple unit converter extension demands the same access, it's definitely a huge red flag.

Step 3: Unpack and Inspect the Actual Source Code

Most people don't go past step 2 because source code inspection somewhat feels like a very complex job. But, in reality, it isn't that hard. Most browser extensions are a collection of JavaScript, HTML, and CSS packed in a folder.

Finding the files:

Chrome-powered browsers store files for all the installed extensions on the disk. They organize these extension files by extension ID and version.

# Linux
~/.config/google-chrome/Default/Extensions/<EXTENSION_ID>/<VERSION>/

# macOS
~/Library/Application Support/Google/Chrome/Default/Extensions/<EXTENSION_ID>/<VERSION>/

# Windows
%LocalAppData%\Google\Chrome\User Data\Default\Extensions\<EXTENSION_ID>\<VERSION>\

If the Default folder is not present, find something like Profile 1, Profile 2, and so on. That's where you have to go.

Use the extension ID you grabbed earlier in step 1 (see above) to switch to the correct extension folder you are trying to audit.

And what about Firefox extensions? These .xpi files are just ZIP archives. Unzip them like this:

cd ~/Downloads
cp extension.xpi extension.zip
unzip extension.zip -d extension_unpacked

Reading the manifest easily with jq:

cat manifest.json | jq '{name, version, permissions, host_permissions, background, content_scripts}'

If the manifest file is large, using the jq command ensures you only get the data you want to inspect instead of scrolling through the entire file.

Scanning the JavaScript for suspicious patterns:

Now, here our goal is not to become a system-level reverse engineer, but to look for common and specific red-flag functions in the JavaScript code.

grep -rniE "eval\(|new Function\(|document\.write|atob\(|btoa\(|fetch\(|XMLHttpRequest|chrome\.cookies|chrome\.history" ./extension_unpacked --include="*.js"

Here's what the usage of these functions indicates:

eval() / new Function() - The code the extension is trying to execute is not present in the file. It's either fetched from a remote source or is dynamically decoded at runtime.
atob() / btoa() - May be trying to encode or decode Base64 strings, which is often used to hide what’s being sent out.
fetch() / XMLHttpRequest - Firing outbound network requests. Check what the destination of these requests is.
chrome.cookies/chrome.history - Making API calls to fetch sensitive browser data.

These functions in themselves are not malicious or bad. It's all about how they are used and what for. If you see a lot of obfuscated code in the extension's source code, it's an alarming situation. Similarly, network requests with encoded strings are also not a good sign.

Step 4: Watch What It Actually Talks To

Inspecting source code can only give you an idea of what bad could happen. But, monitoring the extension's live behaviour tells you what's actually happening.

📷 Fetch/XHR network requests in Chrome DevTools

Quick method - Chrome DevTools:

First, open DevTools (either use the F12 key or right-click → Inspect option from the context menu).
Switch to the Network tab.
Click on the funnel icon to filter the network requests by Fetch/XHR.
Continue browsing for a few minutes and make sure the extension in question is in an active state.
Now see if the request destinations are pointing to unexpected or shady third-party domains.

Deeper method - a local proxy

If you strongly suspect that something is fishy with a specific extension, route the network traffic through a proxy so that you can inspect every single outbound network request.

First, install mitmproxy.
```
pip install mitmproxy
```
Start it on port 8080.
```
mitmproxy -p 8080
```
You'll get an interactive UI in the terminal where every network request going through port 8080 will be displayed in real time.
Open your browser's network/proxy settings and set both HTTP and HTTPS proxy to 127.0.0.1:8080. Remember, this is an OS-level network setting, so make sure you revert it to the previous state after the audit is complete. You can also use a browser extension like FoxyProxy to quickly set the desired proxy without fiddling with the system settings.
Next, install the mitmproxy CA certificate. To do that, make sure the proxy is running, and then visit mitm.it in your web browser and install the certificate for your OS/browser. If you do not complete this step, HTTPS sites will throw certificate errors because mitmproxy has to decrypt the network traffic to show it in the terminal UI.
Disable all other extensions so that you can focus on the one you want to audit.
Now casually browse the internet for a few minutes and leave it idle, keeping the browser tab open.
Switch to the mitmproxy terminal window and look for the following red flags:
- Outbound requests to domains that are shady and have no connection with the extension's functionality.
- Connections happening in repeated patterns as if governed by a timer.
- Continuous connection requests even when the browser is in an idle state.

All these red flags indicate that the extension is collecting data in the background instead of doing its normal job.

Step 5: Investigate the Developer and Update History

Sometimes, checking developer and update history alone gives strong indications if the extension is trustworthy or not.

Here's what to check for:

Developer identity: If it is listed as anonymous or has a real name (individual or company) with a proper support channel.
Update history: If there is a huge spike in updates or a long-abandoned extension has suddenly started receiving quick updates.
Privacy policy: Does the privacy policy exist, and if yes, does it clearly tabulate what data is collected and why?
Review patterns: If recent reviews are complaining about the extension's weird behaviour, it's clearly a warning sign that cannot be overlooked.

Red Flags Cheat Sheet

Here's a quick checklist you can refer to while auditing an extension:

An extension asking for broad host permissions (<all_urls>) without enough justification.
Wants access to cookies, history, and tabs when all the extension does is to display color palettes.
Tons of obfuscated or minified code having no source repository for the public.
Continuous outbound network requests to shady domains even when the browser is idle.
An increase in the extension's permission list soon after transfer of ownership to a new developer.
Either the privacy policy is absent, or it's not clear what data is collected.
Increase in negative reviews stating unexpected extension behaviour.
An extension still sticking with Manifest V2 with no indication of future migration roadmap.

Conclusion

Browser extensions are the least-paid-attention software among general users when it comes to security and privacy. You just search for it, read its features, and install it!

Learn to audit browser extensions to prevent any data theft that may cost you both time and money. The audit process may look overwhelming at first, but it's actually not that difficult.

So, next time you install a new browser extension, make sure to audit its source code first.