extuno
Test extensions and packages for vulnerable code and unsafe APIs
Extuno reads the full code of a browser extension or developer package and flags the parts that put users at risk: dangerous sinks, unsafe browser and Node APIs, and outdated libraries with known issues. Each finding names the file, the line, and what to fix.
What does vulnerability testing actually check?
Extuno checks four families of weakness in an extension or package. First, vulnerable code paths: data that flows from an untrusted source into a dangerous operation without validation. Second, unsafe browser and Node APIs: calls that expand the attack surface or run code that was not reviewed. Third, DOM-XSS sinks: assignments that write attacker-controllable strings into the page as HTML or executable script. Fourth, known-vulnerable bundled libraries through software composition analysis (SCA), where a third-party library shipped inside the bundle has a published defect. Each check is one of the 1100+ static rules that read the code without running it.
How does Extuno find DOM-XSS sinks?
DOM-XSS happens when a value the attacker controls reaches a sink such as innerHTML, outerHTML, document.write, insertAdjacentHTML, or a dynamic script element. Extuno traces the flow from sources like the URL, page messages, or storage to those sinks, then reports the exact write that is unsafe. It also recognizes when a value passes through a recognized sanitizer first, so a properly cleaned flow is not flagged. This is part of Extuno's static analysis, which inspects the source rather than guessing from behavior alone.
How are unsafe APIs and dangerous capabilities handled?
Some APIs are dangerous because they run code or hand over control. Extuno flags eval and the Function constructor, remote code loaded then executed, native messaging, the debugger and management permissions, and broad host access. For Node packages it flags child_process spawning, install-time script hooks, and dynamic module loading. A capability is not the same as proof of malice, so single dual-use signals are rated as review rather than critical, and they escalate only when they combine with exfiltration or a network sink. You can read how scores are assigned on risk scoring.
What does software composition analysis (SCA) cover?
Many extensions and packages bundle third-party libraries directly in the shipped code. Extuno fingerprints those libraries, identifies the version, and compares it against known-vulnerable and known-compromised releases. An outdated library with a published defect is reported at the defect's own severity, and an exact backdoored or protestware release is reported as critical. To cut noise, generic heuristics that fire inside a recognized clean library are suppressed, while a library file that also carries a strong signal such as a leaked secret or an exfiltration call is treated as trojaned and never silenced.
What do I get back from a test?
Every finding carries evidence: the file, the line, why the code is dangerous, and the recommended action. You can review results in the report view, or pull machine-readable SARIF and JSON for your pipeline. Extuno also runs dynamic sandbox analysis to record the endpoints and data a package touches at runtime, and version diffing to catch a library or code path that turns dangerous in an update. See a worked example on the sample report page.
Can I run this in CI/CD?
Yes. Extuno emits SARIF for inline pull-request annotations and a pass/fail gate you configure with the severities or categories that should block a build. A package that introduces a DOM-XSS sink, a known-vulnerable library, or an unsafe API call can fail the gate before it ships. GitHub Action, GitLab CI, and pre-commit recipes are available, and the same evidence-based findings appear in the report and the gate output. Extuno is free to use with a free tier plus paid scan-credit packs.
{
"rule_id": "det.taint.dom_xss",
"severity": "high",
"category": "vulnerability",
"file": "content/inject.js",
"line": 142,
"evidence": "el.innerHTML = location.hash.slice(1)",
"why": "URL fragment flows into innerHTML with no sanitizer; attacker-controllable DOM-XSS sink.",
"recommendation": "Sanitize the value or set textContent instead of innerHTML."
}Frequently asked questions
Does vulnerability testing run the code?
Static vulnerability testing reads the code without executing it, so it can flag sinks, unsafe APIs, and vulnerable libraries directly from the source. Extuno pairs it with dynamic sandbox analysis, which runs the package in an isolated microVM to confirm what it does at runtime. The two layers together give both the code-level reason and the observed behavior.
How do you avoid false positives on DOM-XSS?
Extuno traces the flow from an untrusted source to the sink and checks whether the value passes through a recognized sanitizer on the way. A flow that is cleaned before it reaches innerHTML or a similar sink is not flagged. Single static URLs and constant strings written to a sink are also excluded, so only attacker-controllable writes are reported.
What counts as a known-vulnerable library?
Extuno fingerprints bundled third-party libraries, reads the version, and compares it against published vulnerable and compromised releases. An outdated library with a known defect is reported at that defect's severity. An exact backdoored or protestware release is reported as critical, with the file and version as evidence.
Which ecosystems can I test?
Extuno tests twelve ecosystems: Chrome, Firefox, VS Code, JetBrains, Eclipse, Discord client mods, npm, PyPI, WordPress, Composer, and Maven. Browser extensions are checked for unsafe browser APIs and DOM sinks, while npm, PyPI, WordPress, Composer, and Maven packages add Node and Python specific checks such as install-time scripts and child process spawning.
Is vulnerability testing free?
Extuno has a free tier plus paid scan-credit packs, so you can test packages without a contract. The same evidence-based findings appear in the report view and in the CI/CD gate output, and you can pull SARIF and JSON for your own tooling.