← Back to home

For Extension Vendors

We want to get it right. If you build a browser extension, here is how to work with us.

Our commitment

We analyse what extensions actually do, not just what permissions they request. We know that legitimate tools like VPNs, ad blockers, and password managers require broad permissions to function. Our goal is to distinguish genuinely malicious behaviour from expected functionality.

We understand that many legitimate extensions perform actions that look suspicious out of context. A password manager reads form inputs. A VPN proxies network traffic. An ad blocker injects content scripts into every page.

Our analysis pipeline is designed to evaluate behaviour in context, not flag permissions blindly. When we identify a concern, we look at what data is accessed, where it is sent, and whether that matches what users were told the extension does.

Dispute a finding

If your extension has been flagged and you believe the finding is incorrect, email us. We respond within 5 business days and will re-evaluate with any context you provide.

To dispute a finding or provide context about your extension's behaviour, email vendors@amibeingpwned.com with:

  • Your Chrome Web Store extension ID
  • A description of the flagged behaviour and why it is expected for your extension's functionality
  • Any relevant documentation, architecture notes, or code references that provide context

We will review your submission and respond within 5 business days. If we determine the finding was a false positive, we will update our database and notify any affected enterprise customers.

What we look for

We analyse actual runtime behaviour, not just permissions. Our pipeline covers data exfiltration, injected code, network tampering, obfuscation, and known vulnerabilities.

Our analysis checks for the following categories of behaviour:

  • Data collection - what user data the extension accesses and where it sends it
  • Insecure internal messaging - How the extension communicates internally and with native applications
  • Code injection - scripts injected into web pages and what they do
  • Network behaviour - requests made to external servers, proxying, and traffic interception
  • Obfuscation - whether code is deliberately obscured beyond standard minification/bundling
  • Known vulnerabilities - outdated dependencies, insecure storage, and unvalidated remote code execution paths

We distinguish between standard build tooling output (webpack/rollup minification, tree-shaking) and deliberate obfuscation intended to hide behaviour.

Responsible disclosure

If we find a vulnerability in your extension, we will contact you directly before publishing any findings. We follow coordinated disclosure practices.

When our analysis uncovers a security vulnerability in an extension, we follow a coordinated disclosure process:

  1. We contact the extension developer directly with a detailed report of the finding
  2. We provide a reasonable remediation window (typically 90 days) before any public disclosure
  3. We work with you to verify that fixes are effective
  4. Enterprise customers are notified of the risk level but not given exploit details during the remediation window

To ensure we can reach you, consider adding a security contact to your Chrome Web Store listing or including a security.txt in your extension's website.