Zum Hauptinhalt springen

JavaScript / TypeScript · SAST

JavaScript- und TypeScript-SAST, das vollständig offline läuft

Auditieren Sie Ihre Node.js-Backends und Front-End-Frameworks (React, Vue, Angular, Svelte) auf XSS, Prototype Pollution, Injection-Fehler und Supply-Chain-Risiken — ohne eine einzige Zeile in die Cloud hochzuladen.

Geprüfte Frameworks & Bibliotheken

Wir testen die Abdeckung über Fixtures auf diesen Frameworks. Neue Muster werden in jedem Builtin-Regel-Release ergänzt.

Express Fastify Next.js Nuxt NestJS Hapi React Vue Angular Svelte Mongoose Sequelize Prisma TypeORM Knex jsonwebtoken cookie-parser

Häufigste erkannte CWE-Klassen

Diese CWE-Klassen treten in modernen Codebasen dieser Sprache am häufigsten auf. StaticCodeAudit liefert dedizierte Regeln für jede, gemappt auf OWASP Top 10 / ISO 27001 / ASVS, sofern relevant.

CWE-79

Cross-Site Scripting (XSS)

innerHTML, dangerouslySetInnerHTML in React, v-html in Vue, Angular bypassSecurityTrust* mit User-Daten. Stored-, Reflected- und DOM-basierte Varianten abgedeckt.

Erkannt von SCA-Regel: xss_innerhtml

CWE-1321

Prototype Pollution

Rekursive Object.assign, _.merge, oder ungeschütztes obj[key] = value wenn key vom User kommt. Ein einziger __proto__-Key kann alle nachgelagerten Objekte brechen.

Erkannt von SCA-Regel: prototype_pollution

CWE-89

SQL-Injection

Sequelize.literal(), Raw-Queries in Prisma $queryRaw\`${input}\`, Mongoose $where mit Strings, Knex .raw() mit Concat.

Erkannt von SCA-Regel: sql_injection_concat

CWE-918

SSRF

axios.get(url), fetch(url), http.get auf User-URLs. Besonders gefährlich in Serverless via interne Metadaten-Endpoints.

Erkannt von SCA-Regel: taint_ssrf

CWE-798

Hartkodierte Zugangsdaten

In .env.example, config.js committete API-Keys, oder React process.env.REACT_APP_* im Client-Bundle exponiert.

Erkannt von SCA-Regel: hardcoded_secret

CWE-915

Mass Assignment

User.update(req.body) ohne Field-Allowlist. Lässt Angreifer Privilegien eskalieren (isAdmin: true) via JSON-Body.

Erkannt von SCA-Regel: mass_assignment

Verwundbar vs. sicher — drei kurze Beispiele

CWE-79 Erkannt von SCA-Regel: xss_innerhtml
❌ Verwundbar
// Verwundbar — React dangerouslySetInnerHTML
function Bio({ user }) {
    return <div dangerouslySetInnerHTML={{ __html: user.bio }} />;
}
✅ Sicher
// Sicher — Textinhalt, keine HTML-Interpretation
function Bio({ user }) {
    return <div>{user.bio}</div>;
}
CWE-1321 Erkannt von SCA-Regel: prototype_pollution
❌ Verwundbar
// Verwundbar — Deep Merge ohne Proto-Guard
function merge(target, source) {
    for (const key in source) {
        if (typeof source[key] === "object") {
            merge(target[key] = target[key] || {}, source[key]);
        } else { target[key] = source[key]; }
    }
}
✅ Sicher
// Sicher — blockiert __proto__/constructor
function merge(target, source) {
    for (const key of Object.keys(source)) {
        if (key === "__proto__" || key === "constructor") continue;
        if (typeof source[key] === "object") {
            merge(target[key] = target[key] || {}, source[key]);
        } else { target[key] = source[key]; }
    }
}
CWE-89 Erkannt von SCA-Regel: sql_injection_concat
❌ Verwundbar
// Verwundbar — Concat in Sequelize.literal
const users = await User.findAll({
    where: sequelize.literal(`name = \'${req.query.name}\'`)
});
✅ Sicher
// Sicher — Bind-Parameter
const users = await User.findAll({
    where: { name: req.query.name }
});

Was StaticCodeAudit erkennt (diese Sprache)

  • XSS in React dangerouslySetInnerHTML, Vue v-html, Angular Trust Bypass, Vanilla innerHTML
  • Prototype Pollution via Deep Merge, dynamische Key-Zuweisung
  • SQL-Injection in Sequelize, Mongoose, Prisma, TypeORM, Knex Raw-Queries
  • NoSQL-Injection (Mongoose $where mit Strings, Mongo-Operatoren in User-Input)
  • SSRF via axios, fetch, http mit User-URLs
  • Hartkodierte Secrets (API-Keys, JWT-Secrets, AWS, Stripe, GitHub, Slack-Tokens)
  • Mass Assignment in Sequelize/Mongoose ohne Field-Allowlist
  • Unsichere Cookies (httpOnly, secure, sameSite Flags)
  • Fehlendes CSRF-Token in Express-Formularen
  • Path Traversal in fs.readFile mit User-Input
  • Unsichere Krypto (MD5 in crypto, hartkodierter IV, schwache Zufallszahlen)
  • Open Redirect (res.redirect(req.query.url))
  • Veraltete Abhängigkeiten via package.json-Muster
  • CI/CD-Fehlkonfigurationen (.gitlab-ci, GitHub Actions, npm Scripts)

Neugierig, wie die Erkennungsqualität tatsächlich gemessen wird? Sehen Sie sich die vollständige sprachübergreifende Benchmark-Methodik an (OWASP Benchmark, NIST Juliet, Precision/Recall/F1 pro Sprache) →

CVE Test Suite — die ehrliche Zahl für Express

StaticCodeAudit wurde gegen eine reale CVE Test Suite gemessen: 45 Fälle, rekonstruiert aus veröffentlichten, historischen CVEs über 8 Frameworks und 5 Sprachen. Express ist eines davon — und das zweitschlechteste Framework der gesamten Suite.

76,1%
F1-Score
80,0%
Recall
45
CVE Test Suite (gesamt, alle Sprachen)

Express, aus CVE rekonstruiert

76,1%
Express (aus CVE rekonstruiert)

Offen gelegt, nicht versteckt: Express/JavaScript steht in der sprachübergreifenden CVE-Tabelle an zweitletzter Stelle, Precision bei 72,7%. Komplexe mehrstufige Taint-Pfade durch Middleware-Ketten sind das konkrete Muster, das die Regel-Engine bei manchen Express-CVEs noch übersieht. Vollständige sprachübergreifende Aufschlüsselung (auch wo Python und PHP besser abschneiden) auf der <a href="/de/language-benchmarks.php" class="text-primary font-semibold hover:underline">Sprachbenchmark-Seite</a>.

Echte Schwachstellen passen selten in eine einzige Datei

Express-Anwendungen verteilen die Logik auf mehrere Schichten: ein Route-Handler empfängt die Anfrage, ein Datenzugriffsmodul baut die Abfrage. Ein Scanner, der jeweils nur eine Datei sieht, verbindet die beiden nie — er sieht die Nutzereingabe in routes/orders.js und den Datenbankaufruf in db/orders.js, aber nie die Verbindung dazwischen. StaticCodeAudit verfolgt die Daten über Dateigrenzen hinweg.

routes/orders.js
router.get('/orders', (req, res) => {
    const id = req.query.id;
    res.json(findOrder(id));
});
db/orders.js
function findOrder(id) {
    const sql = `SELECT * FROM orders WHERE id = ${id}`;
    return db.query(sql);
}

id stammt aus dem Query-String im Route-Handler und erreicht die SQL-Abfrage eine Datei später unverändert — StaticCodeAudit meldet dies genau in der Zeile, in der die Abfrage ausgeführt wird.

Wie schneidet das im Vergleich zu ESLint oder Semgrep ab?

ESLint (mit Security-Plugins wie eslint-plugin-security) und Semgrep sind die zwei Tools, die als Erstes genannt werden, wenn ein JavaScript-/TypeScript-Team nach einem kostenlosen Security-Scanner sucht. Beide sind legitim, und viele Teams nutzen bereits eines davon — hier ein ehrlicher Vergleich, keine Abwertung.

ESLint + eslint-plugin-security

Kostenlos, Open Source

Bereits Teil der meisten JS/TS-Toolchains, daher kostet das Hinzufügen des Security-Plugins fast keinen Konfigurationsaufwand. Die Abdeckung wird von der Community gepflegt und ist musterbasiert (z. B. markiert eval, unsichere Regex) — kein dateiübergreifendes Taint-Tracking, und Findings sind standardmäßig nicht auf CWE/ISO 27001/ASVS gemappt.

Semgrep (Community)

Kostenlos, Open-Source-Kern

Pattern-Matching-Engine, die viele Sprachen abdeckt, darunter JS/TS, mit einem großen offenen Regel-Register. Der kostenlose Tier deckt die meisten Alltagsregeln ab; dateiübergreifendes Taint-Tracking, Compliance-Reporting und einige Enterprise-Integrationen sind Semgreps kostenpflichtigen Tiers vorbehalten.

Vollständiger Vergleich StaticCodeAudit vs. Semgrep →

Keines der beiden wird durch die Installation von StaticCodeAudit ersetzt — wenn Ihre ESLint-Konfiguration bereits das abdeckt, was Ihr Team braucht, nutzen Sie sie weiter. Was StaticCodeAudit hinzufügt: Findings, die bereits auf CWE/OWASP/ISO 27001/ASVS/NIST CSF gemappt sind (ein Finding, das direkt in eine Audit-Akte passt, nicht nur eine Regel-ID), dateiübergreifendes Taint-Tracking über Ihre Routen und Module standardmäßig, und 7 weitere Sprachen, die von derselben Binary abgedeckt werden — kein separater Scanner pro Sprache zu konfigurieren. Viele Teams nutzen beides.

Auditieren Sie Ihren Code

Auditieren Sie Ihre Node.js-Backends und Front-End-Frameworks (React, Vue, Angular, Svelte) auf XSS, Prototype Pollution, Injection-Fehler und Supply-Chain-Risiken — ohne eine einzige Zeile in die Cloud hochzuladen.

Demo-Binary herunterladen Geführte Demo buchen