Engineering service
Extension Security Audit & Bug Finding
We audit your extension's permissions, code, and runtime behavior to find what an attacker could exploit, then help you fix it.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
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 a security review 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 we engineer: Extension Security Audit & Bug Finding
Threat Modeling & Attack Surface Mapping
Map what the extension can read, which sites it runs on, and where attacker-controlled input enters before we write a single test case.
Manifest & Permission Review
Line up every requested host and API permission against the feature that actually uses it, and flag the ones that do not.
Content Script & Injection Review
Read content script code for DOM XSS sinks, such as innerHTML or eval-like calls fed by untrusted page data.
Message Handler & Origin Checks
Verify that runtime and window message listeners check sender and origin before acting on the payload.
Dynamic Exploit Testing
Run the extension against crafted pages and messages to confirm which findings are actually exploitable.
Remediation & Fix Verification
Apply fixes when that is part of the engagement, then retest each finding to confirm it is closed.
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 real-world impact, not just by vulnerability category.
Manifest, Code, and Runtime, Together
The review covers the static manifest, the source, and the extension running against hostile input, not just one of the three.
A Separate Track from Functional QA
Compatibility and performance testing are out of scope here; that work is a separate service, so this review stays focused on exploitable risk.
Our approach
How an 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 few cases where this approach may not be the best choice for you.
- 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 behind our extension security audit & bug finding work.
FAQ
Questions engineers ask before starting
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.
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
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.
