1. Package intake
A package can be a Chrome CRX, a Firefox XPI, a ZIP or a standalone manifest.json. The browser applies a 25 MB upload limit before reading the file. The analyzer detects the CRX2 and CRX3 container headers, strips the header, and treats the remainder as a ZIP archive. A bare manifest.json is analyzed as a single manifest with no source files.
2. Safe unpacking
Archive processing runs in a Web Worker. Before reading entries, the analyzer enforces entry count, per-file size and total uncompressed size limits. Path traversal segments, absolute paths and symlinks are rejected or skipped. Nested archives are not expanded beyond a small fixed limit. Skipped content is listed in the report so a result is never presented as more complete than it is.
3. Manifest analysis
The manifest is parsed as data and validated with a permissive schema so minor real-world variations do not break analysis. The analyzer collects the extension name, version, manifest version, browser-specific fields, required and optional API permissions, host permissions, content scripts, background configuration, CSP, update URL, externally_connectable, web-accessible resources, action popup and options page. Missing or malformed fields generate warnings rather than silent failures.
4. Static code inspection
JavaScript and HTML files are read as text within strict size limits. JavaScript is parsed with an ECMAScript parser to locate patterns such as eval, the Function constructor, string-based timers, remote script loading, importScripts(), DOM injection APIs, storage APIs, messaging, native messaging, cookie access, password-field references and keyboard event listeners. HTML is scanned for inline and remote script references. No code is executed, imported or installed. Findings include file, line, column, evidence, confidence and a plain-language explanation.
5. Domain extraction
URLs found in manifests, scripts and HTML are reduced to hostnames. Local, extension and placeholder hosts are removed. Each remaining domain is grouped as analytics, advertising, authentication, error reporting, cloud service or unknown. A referenced domain is a static reference only; it does not prove that the extension contacted it.
6. Risk scoring
Six category scores (0-100 each) are weighted and summed. Category scores are rounded before weighting. The final score is rounded to the nearest integer and mapped to a band.
| Category | Weight | What contributes |
|---|---|---|
| Permission exposure | 25% | Required API permission weights, broad-access flags |
| Website access | 20% | Host patterns, all-sites access, content-script matches |
| Data collection indicators | 15% | Storage, network APIs, sensitive fields, cookies, history |
| Remote code indicators | 20% | Dynamic execution, remote scripts, runtime imports |
| External domain exposure | 10% | Unique external domains, ad-tech and unclassified hosts |
| Source obfuscation | 10% | Strong obfuscation indicators and their severity |
Bands: 0-24 low, 25-49 moderate, 50-74 high, 75-100 critical. Each category displays its score, weight, weighted contribution and the evidence used.
What the score is not
The score is not a malware verdict, a reputation score or a guarantee. Static analysis cannot observe runtime behavior, server-side logic, dynamic updates or future versions. Legitimate extensions can score high because they need broad access. Use the evidence and permissions list, not only the number.
Versioning and corrections
The report includes a schema version so exported JSON can be interpreted consistently. Scoring weights and detection rules may change as the tool improves. If you find a systematic false positive or a missed pattern, please contact us with the package details.
Ready to inspect a package? Open the analyzer.