1. Overview
Extenshi provides automated security signals for browser extensions listed in our public catalog. These signals are generated by running multiple static analysis tools against publicly available extension source code. The results are informational and do not constitute a professional security audit.
Our scanning pipeline is fully automated. No human reviews individual extension results before publication. This page explains how the analysis works, how scores are calculated, and what limitations apply.
2. What we scan
We analyze publicly available extension packages, including:
- the extension manifest file (manifest.json) and declared permissions,
- JavaScript, TypeScript, HTML, and CSS source files,
- declared dependencies (package.json, CDN references),
- external URLs and resource references.
Scanning is performed statically — we do not execute extension code or observe runtime behavior.
3. Core analyzers
3.1 Manifest analyzer
Validates manifest.json structure and classifies declared permissions by risk tier. Checks for overly broad host permissions, content security policy configuration (e.g., usage of unsafe-eval or unsafe-inline), web accessible resources with wildcard patterns, and externally connectable settings.
3.2 Security analyzer
Pattern-based detection of potentially dangerous code constructs such as eval(), innerHTML assignment, document.write(), dynamic script execution, and external script loading. Also runs ESLint-based security rules for regex safety, buffer handling, and unsanitized DOM manipulation.
3.3 Code quality analyzer
Measures code structure and maintainability metrics including function length, nesting depth, file size, and presence of debug statements. Also checks HTML for accessibility and deprecated elements.
3.4 Dependency analyzer
Identifies declared and inlined third-party libraries, detects deprecated packages, and checks against known vulnerability databases (including CVE references for common libraries like jQuery and Lodash). Catalogs CDN dependencies.
3.5 External links analyzer
Catalogs all external URLs and resource references found in manifest files, HTML, JavaScript, and CSS. Groups links by type and domain for transparency. This analysis is informational and does not assign safety scores to individual URLs.
4. Supplementary scanners
In addition to the core static analysis, we may run supplementary scanners including:
- Machine learning-based analysis: classification of JavaScript patterns using token, AST, and control flow graph analysis.
- URL and secret extraction: automated extraction of URLs and potential secrets from JavaScript source.
- Antivirus scanning: scanning extension packages against known malware signatures.
- License and component detection: identifying open source components and their licenses.
5. Scoring methodology
Each scan first produces a raw findings score (0–100) — a weighted sum of findings, normalized by extension size:
- Critical findings: 10 points each
- High findings: 5 points each
- Medium findings: 2 points each
- Low findings: 1 point each
The raw findings score is normalized relative to the number of files analyzed, then capped at 100. This means larger extensions are not penalized simply for having more code.
The user-facing number is the safety coefficient, computed as 100 − findings score. A higher safety coefficient means fewer or less severe findings.
Safety bands based on the safety coefficient (0–100, higher is safer):
- 85–100: minimal or no findings
- 61–84: minor findings
- 41–60: moderate findings, review recommended
- 21–40: significant findings
- 0–20: numerous or critical findings
6. Severity classification
Each finding is assigned a severity level:
- Critical: patterns strongly associated with security vulnerabilities (e.g., dangerous permissions, known CVEs, missing manifest).
- High: patterns that may indicate security concerns requiring attention.
- Medium: patterns that warrant review but may be benign in context.
- Low: code quality observations and best practice recommendations.
- Info: informational observations with no security implication.
Each finding also carries a confidence level (0.7–1.0) indicating how reliably the pattern indicates an actual issue. Higher confidence means less likelihood of a false positive.
7. Limitations
Our automated analysis has inherent limitations:
- Static analysis only: we do not execute extension code. Runtime behavior, network requests, and dynamic code loading cannot be observed.
- False positives: pattern-based detection may flag benign code that matches dangerous patterns. For example, a legitimate use of eval() in a sandboxed context.
- False negatives: sophisticated obfuscation, encrypted payloads, or novel attack vectors may not be detected.
- Context-free: our scanners cannot determine whether a flagged pattern is actually exploitable in the extension's specific context.
- Point-in-time: results reflect the extension version analyzed and may not represent the current published version.
- No guarantee: a high safety coefficient does not guarantee safety, and a low one does not prove malicious intent.
The security signal should be used as one factor among many when evaluating an extension, not as a definitive safety verdict.
8. Disputes and corrections
If you are an extension developer and believe your extension's security signal is inaccurate or misleading, you may submit a correction request through our developer dispute process. We review all dispute submissions and will update results where appropriate.
Contact: [email protected]