Engineering service
Extension security audit
Find what an attacker could exploit in your extension, then fix it. We review the permissions, the code and the running extension for Chrome, Firefox, Edge, Brave and Safari. This is a security review; for functional and compatibility testing, see browser and extension QA testing.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
An extension can read pages, act on behalf of the user and talk to remote servers, so a weakness in it can affect every site the user visits. Common problems include permissions that are broader than needed, unchecked messages and code that trusts page content.
We review the manifest, the source and the running extension, then report what we found and how to reproduce it. We can also fix the issues, if agreed up front. No review can promise that nothing remains, so every report states what was tested and how.
Who this is for
- Teams about to publish or update an extension that requests broad permissions.
- Products that handle user data, credentials or page content and need an independent review.
- Companies whose customers or store reviewers have asked how the extension was reviewed.
- Teams that inherited an extension codebase and do not know what it exposes.
How it works
How an audit runs
The review follows the way an attacker would approach the extension, starting from what it can access.
Threat model
Map what the extension can access, who can send it data and what an attacker would want.
You get: A model of assets and entry points
Permission review
Compare the manifest against what the features actually need.
You get: Permissions to remove or make optional
Code review
Read the source for unsafe injection, weak message handling and stored secrets.
You get: Findings tied to files and lines
Dynamic testing
Run the extension against hostile pages and crafted messages to confirm what is exploitable.
You get: Confirmed issues with proof
Report and fixes
Deliver findings with severity, reproduction steps and recommended fixes, or apply the fixes if agreed.
You get: A written report
Retest
Check that each fix closes the issue and did not open a new one.
You get: Confirmation per finding
What we offer
What's included
Content scripts and page injection
DOM XSS sinks such as innerHTML or eval-like calls fed by page data, and content scripts that leak extension data back to the page.
Message handlers and external access
Runtime and window message listeners that act without checking sender and origin, and web pages or extensions allowed to message yours.
Tokens, storage and sign-in
Where tokens, cookies and user data are kept, which parts of the extension can read them, and how the sign-in flow could be abused.
Native hosts and backend endpoints
Native messaging hosts and the APIs the extension calls, checked for commands or data an attacker could reach through the extension.
Publishing and supply chain
Store account security, who can publish, how releases are reviewed, and the third-party packages in the build. In December 2024, phished developer accounts were used to push malicious updates to several extensions.
Exploit testing and retest
Crafted pages and messages that confirm which findings are actually exploitable, then a retest of each fix.
Deliverables
What you get
- 01
Threat model
A short description of what the extension can reach and where untrusted input enters.
- 02
Findings report
Each issue with severity, reproduction steps, affected code and a recommended fix.
- 03
Permission recommendations
A least-privilege manifest proposal, including which permissions could become optional.
- 04
Fixes if agreed
Code changes for the issues found, when fixing is part of the engagement.
- 05
Retest results
Confirmation that each fixed issue is closed, recorded against the original finding.
- 06
Shareable summary
A shorter summary written for store reviewers or your customers, on request.
Compare
What we check
The scope is agreed per extension. These are the areas we start from.
| Area | Typical problem | What we look for |
|---|---|---|
| Permissions | Broad host or API permissions that features do not need. | A least-privilege manifest and permissions that can be requested optionally, when needed. |
| Content scripts | Untrusted data injected into pages. | DOM XSS sinks such as innerHTML and eval-like calls fed by page or server data. |
| Messaging | Accepting messages from any web page or extension. | Sender and origin checks on runtime messages and window messages. |
| Secrets and auth | Keys or tokens shipped in the package or stored insecurely. | How the OAuth flow works and where tokens and credentials are stored. |
| Remote content | Loading or executing code fetched at runtime. | Content security policy settings and third-party scripts. |
| Dependencies | Vulnerable or unmaintained packages. | Dependency audit results and the integrity of the build process. |
Why it matters
What this gives you
Findings tied to exact code
Each finding names the file, function and line involved, so a developer can act without re-deriving the bug.
Ranked by what an attacker could do
Findings are ordered by the harm they could do to your users and their data, not by vulnerability category.
Fewer permissions, milder install warnings
Cutting permissions the features do not use shrinks what an attacker could reach and softens the warning users see before they install.
Manifest, code and runtime together
One review covers the manifest, the source and the extension running against hostile input, so issues that only show up in combination are found.
Our approach
How an audit engagement runs
Scope and access
You share the source, a build, test accounts and an architecture overview, and we agree scope and rules.
You get: An agreed scope
Review
We work through the manifest, code and running extension, and flag serious issues as soon as we confirm them.
You get: Early notice of serious findings
Report
We deliver a written report and walk your team through it.
You get: A report and a review session
Fix and retest
Your team or ours fixes the issues, as agreed, and we retest each one.
You get: Retest results
When this is not the right fit
- A certification or guarantee that no vulnerabilities remain. We report exactly what we tested and how.
- Functional bugs, compatibility problems or performance regressions. Those belong to the extension QA service.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
FAQ
Common questions
Both are possible, and we agree which up front. Some teams want a report their developers act on, and others want us to make the fixes.
No. We review extensions for Chrome, Edge, Firefox, Brave and Safari, and we pay attention to where their extension models differ.
The source code, a working build, test accounts and an overview of the architecture. If some parts are out of scope, tell us and we will note it in the report.
The full report contains details you will probably want to keep private. We can write a shorter summary intended for store reviewers or customers.
No review can promise that. We report what we tested, how we tested it and what we found, so you know what the review did and did not cover.
Our services
Related services
Start a project
Get your extension audited by browser engineers
Send us the extension and its permission set. We will find what an attacker could exploit and help you fix it.
