Scoring Methodology

Last updated: May 7, 2026

This page describes how Extension Auditor analyzes browser extensions and produces the risk classifications you see on scan pages. Our goal is transparency: developers, researchers, and end users should be able to understand the basis on which we classify an extension and challenge classifications they believe are wrong.

Important. Extension Auditor's risk classifications are automated analytical opinions based on technical signals. They are not statements of fact about the extensions or their developers, and they should not be treated as a substitute for independent security review or professional advice. See our Terms of Service and Privacy Policy for the full disclaimer and lawful basis on which we publish this analysis.

What we analyze

For every extension we score, we collect and analyze the following signals from public sources:

Manifest and permissions

• The full manifest.json declared by the extension
• All requested permissions (e.g., tabs, storage, webRequest, cookies)
• All host permissions (the URLs the extension may access)
• Content scripts and the URL patterns they match against
• Background scripts, service workers, and their scopes
• Externally connectable origins
• Optional permissions and host permissions

Code analysis

• Static analysis of all bundled JavaScript and HTML/CSS
• Detection of known dangerous code patterns (e.g., dynamic eval, remote code loading, obfuscated payloads)
• Extraction of network endpoints, IP addresses, email addresses, cryptocurrency addresses, and other indicators of compromise
• Comparison against known-malicious code patterns from public threat intelligence

Publisher and listing signals

• Publisher name, contact email, and verification status as published in the Chrome Web Store
• The set of other extensions published by the same developer account
• Listing metadata (description, category, install count, ratings, version history)
• Changes to publisher email or other identity signals over time

Marketplace signals

• Removal status from the Chrome Web Store (active, unlisted, removed)
• Reasons for removal where publicly disclosed (malware, policy violation, voluntary)
• Cross-references to other public databases of malicious or compromised extensions

How risk is classified

Each detected signal is assigned a severity tier and a weight:

The detected signals are aggregated into a numerical score, and that score is mapped to a risk level:

Certain combinations of permissions trigger a dangerous-combination multiplier that increases the contribution of those permissions to the aggregate score. For example, an extension that combines webRequest, webRequestBlocking, and broad host access has elevated capacity to intercept and modify network traffic; this combination is scored more heavily than the sum of its parts.

What we do not classify on

We deliberately exclude the following from our scoring:

• Subjective quality judgments. We do not score extensions on user experience, design quality, or feature completeness.
• Developer demographics. We do not score extensions based on the developer's nationality, organization size, or any protected characteristic.
• Marketplace popularity. Install count, rating, and review count are recorded as context but do not directly affect the risk score. A popular extension is not "safer" by virtue of popularity.
• Manual editorial decisions. Risk scores are produced by automated analysis. Human review may be applied to validate findings or address removal requests, but does not by itself raise or lower a score.

Limitations

You should be aware of the following limitations when interpreting Extension Auditor scores:

• Static analysis cannot detect all threats. Code that loads remote payloads at runtime, that activates only under specific conditions, or that is obfuscated using novel techniques may evade detection.
• Extension behavior changes between versions. A score reflects the analyzed version. New versions are re-analyzed, but there is necessarily a window between publication and analysis.
• Permissions are a proxy, not a measurement. Many legitimate extensions request broad permissions for legitimate reasons. The risk classification reflects the capability surface implied by the permissions, not direct evidence of misuse.
• Marketplace metadata can be incorrect. Publisher names, contact information, and verification status are taken from the Chrome Web Store as published. Where this data is wrong, our reports inherit that inaccuracy.
• Legitimate extensions can score HIGH or CRITICAL. A score reflects the analyzed capability and signal surface; it does not by itself prove malicious intent. Consult the detailed scan report and exercise judgment.

Challenging a classification

If you are an extension developer, publisher, or researcher and you believe a classification is unsupported by the underlying signals, you can:

1. Submit a factual inaccuracy report at our Removals & Takedowns page. Include the extension ID, the URL of the scan page, and the specific signals you believe are misinterpreted.
2. Request publication of a developer response alongside the scan report. We may, at our discretion, publish your response so readers see both perspectives.
3. Exercise statutory data-subject rights under GDPR, CCPA, or PDPA where applicable, as described in our Privacy Policy and Removals & Takedowns policies.

We respond to factual inaccuracy reports within 14 days. We do not commit in advance to making any specific change, but every report is reviewed by a human.

Methodology updates

This methodology evolves as we improve our analysis pipeline and incorporate new threat intelligence. Material changes will be reflected in the "Last updated" date at the top of this page. Where a methodology change materially affects existing scan reports, we re-score affected extensions and note the change in our changelog.