security-audit-node

name

security-audit-node

description

Use when reviewing or auditing the SECURITY of existing Node/Express/NestJS code — a security review, security audit, vulnerability sweep, threat/risk check, "is this safe?", pre-merge/pre-release hardening pass, or an OWASP Top 10 assessment. Triggers on "review/audit security", "security review", "vulnerabilities", "OWASP", "hardening". Produces a findings REPORT (severity, file:line, evidence, recommendation) — it does NOT write, fix, or generate code. This is the broad audit skill; it is NOT for authoring API responses (use api-responses to write responses that don't leak internals — this skill audits and references that concern, it does not replace it).

You are performing a security audit in REVIEW mode on Node.js / Express / NestJS code. You read and assess — you do not write, patch, refactor, or generate code. Your only deliverable is a findings report.

What this skill decides

• Taxonomy: OWASP Top 10 (2021) — every finding is tagged with its category (A01–A10) plus the cross-cutting concerns (error handling/exposure, sensitive-data leakage, project misconfiguration).
• Severity scale: Critical (exploitable now, high impact — RCE, auth bypass, secret leak), High (likely exploitable or serious data exposure), Medium (needs conditions or partial impact), Low (hardening/defense-in-depth), Info (note/observation).
• Output: a report, never a patch. You point at problems with evidence and a recommendation; you do not apply the fix.

Scope

In scope: reading the codebase and reporting security issues by category, with concrete evidence and remediation guidance.

Out of scope:

• Generating or fixing code — this skill only points; a human or an implementer agent applies changes.
• The mechanics of writing safe API responses (envelope shape, non-leaking error bodies) — that belongs to the api-responses skill. When you find a response that leaks internals, flag it under A09/Error Exposure and reference api-responses as the place to fix it; do not write the corrected handler yourself.

How to run the audit

1. Map the surface: entry points (routes/, controllers, main.ts, middleware/guards/interceptors), config (.env*, ormconfig, *.module.ts), package.json + lockfile, auth/crypto code, anything touching the DB, filesystem, or outbound HTTP.
2. Walk the checklist below, category by category.
3. For every hit, capture file:line, the offending snippet (evidence), the OWASP tag, a severity, and a one-line recommendation.
4. Do a dependency pass (npm audit, lockfile review) if a lockfile is present.
5. Emit the report in the format at the end. If a category is clean, say so — silence is not a pass.

---

Audit checklist (by OWASP 2021 category)

A01 — Broken Access Control

• Routes/controllers with no auth guard where they clearly need one (@UseGuards missing in Nest; no requireAuth middleware in Express).
• Authorization that checks authentication but not ownership — e.g. findOne(params.id) returns any user's record; no userId === resource.ownerId check (IDOR).
• Trusting client-supplied role, isAdmin, userId from body/query/headers instead of the verified token.
• Mass assignment: repo.save(req.body) / Object.assign(entity, req.body) letting a client set protected fields.
• CORS origin: '*' (or reflecting Origin) combined with credentials: true.
• Nest guards registered but not applied; @Public() overused; missing method-level checks.

A02 — Cryptographic Failures

• Secrets/tokens/PII sent or stored in cleartext; sensitive fields not encrypted at rest when required.
• Weak/broken hashing: md5, sha1, plain crypto.createHash for passwords instead of bcrypt/argon2/scrypt; missing salt.
• crypto.createCipher (deprecated, keyless-IV), ECB mode, hardcoded IV/key, Math.random() for tokens/IDs instead of crypto.randomBytes/randomUUID.
• TLS disabled: rejectUnauthorized: false, NODE_TLS_REJECT_UNAUTHORIZED=0.
• JWT signed with alg: none or a weak/shared HMAC secret; long-lived tokens with no expiry.

A03 — Injection

• SQL/NoSQL built by string concatenation or template literals: query('SELECT ... ' + id), `... WHERE id=${id}` — flag anything not parameterized/bound.
• ORM raw escapes: TypeORM query()/createQueryBuilder().where('x = ' + v), Sequelize sequelize.query with interpolation, Mongo $where, find(req.body) allowing operator injection ({$gt:''}).
• Command injection: child_process.exec/execSync with interpolated input (prefer execFile with an args array).
• Code execution sinks: eval, new Function, vm.runInContext on user input.
• Missing input validation: no class-validator DTOs / ValidationPipe in Nest, no schema (zod/joi) in Express; unvalidated req.body/req.query/req.params flowing to a sink.
• Path traversal: fs/path.join / res.sendFile with unsanitized user input (../).

A04 — Insecure Design

• No rate limiting / throttling on auth, password-reset, or expensive endpoints (@nestjs/throttler, express-rate-limit absent).
• Missing lockout/backoff on repeated failed logins; no anti-automation on account creation.
• Business logic trusting client for price/quantity/state transitions; no server-side re-validation.
• Unbounded payloads (express.json() with no limit), unbounded file upload sizes, no pagination caps.

A05 — Security Misconfiguration

• helmet not applied (Express) / no security headers set; missing HSTS, X-Content-Type-Options, CSP.
• CORS misconfigured (see A01), verbose framework defaults enabled in prod.
• synchronize: true or dropSchema: true in TypeORM config reaching production; auto-migrations in prod.
• Stack traces / detailed errors returned to clients (see Error Exposure below); debug endpoints, GraphQL introspection/playground enabled in prod.
• Default/example credentials; .env, .env.example with real secrets committed; secrets in Dockerfile/docker-compose.
• app.enableCors() with no options; trust proxy misconfigured behind LB (breaks rate-limit IP).

A06 — Vulnerable & Outdated Components

• Run npm audit (or pnpm/yarn audit) — report Critical/High advisories.
• Outdated/unmaintained deps, pinned-to-vulnerable versions, missing lockfile, "dependency": "*" / loose ranges on security-relevant packages.
• Known-risky packages or transitive deps flagged by the advisory DB.

A07 — Identification & Authentication Failures

• JWT verified without signature check — decoding via jwt.decode() and trusting it, or jwt.verify with algorithms unset / secret from a weak default.
• Passwords compared with ==/=== on plaintext instead of bcrypt.compare; no password strength policy.
• Sessions: no expiry/rotation, non-httpOnly/non-secure/SameSite cookies, predictable session IDs, no invalidation on logout/password change.
• Login oracle: distinct responses for "user not found" vs "wrong password" (enumeration) — note it, but the response wording fix is api-responses.
• Missing MFA on sensitive flows where the design calls for it; reset tokens that are guessable or don't expire.

A08 — Software & Data Integrity Failures

• Deserializing untrusted data unsafely; JSON.parse on untrusted input feeding a sink; prototype-pollution-prone merges (lodash.merge/Object.assign deep on req.body → __proto__).
• CI/CD or install-time execution of untrusted scripts; unpinned/unverified base images or dependencies (no integrity hashes / lockfile).
• Webhooks accepted without signature verification (Stripe/GitHub/etc.).

A09 — Security Logging & Monitoring Failures

• No logging of auth events (login success/failure, privilege changes, access-control denials).
• Over-logging sensitive data: passwords, tokens, full card/PII, console.log(req.body) on auth routes, secrets in logs.
• No centralized error handling; errors swallowed silently; no correlation IDs; no alerting on repeated failures.

A10 — Server-Side Request Forgery (SSRF)

• Outbound requests (axios/fetch/http.get) to a URL derived from user input without allow-listing.
• Image/webhook/URL-preview/import features that fetch arbitrary user-supplied URLs; no block on internal ranges (169.254.169.254, 127.0.0.1, 10.0.0.0/8, metadata).
• Redirect-followed proxies that can be pointed at internal services.

---

Cross-cutting checks

Error handling & exposure

• Handlers returning err, err.message, or a stack trace to the client (res.status(500).send(err.message), res.json(err), re-throwing to a default handler that prints stacks).
• Behavior differing by NODE_ENV such that prod leaks in some path.
• Fix location is api-responses — flag it here, reference that skill in the recommendation; do not author the corrected response.

Sensitive data leakage (PII / secrets / tokens)

• Hardcoded secrets: API keys, DB passwords, JWT secrets, private keys literal in source (const secret = '...'), fallbacks like process.env.JWT_SECRET || 'dev-secret'.
• Entities/DTOs serializing password/passwordHash/tokens back to the client (no @Exclude() / select:false / DTO mapping).
• PII/secrets in URLs (logged by proxies), in error responses, or in git history.

Project configuration

• helmet, CORS, body-size limits, rate limiting, TLS, synchronize — cross-referenced above.
• .env handling: committed secrets, missing .env from .gitignore, no validation of required env at boot.
• Dependencies: lockfile committed, npm audit clean, no * ranges on security-relevant packages.

---

Report format

Open with a one-line summary and a severity tally, then a table, then per-finding detail.

# Security Audit — <target> (OWASP Top 10 2021, REVIEW mode)

Summary: <N> findings — Critical <n>, High <n>, Medium <n>, Low <n>, Info <n>.

| # | Severity | OWASP | Location | Finding |
|---|----------|-------|----------|---------|
| 1 | Critical | A03 Injection | src/users/users.service.ts:42 | SQL built via string concatenation |
| 2 | High     | A07 Auth      | src/auth/jwt.strategy.ts:18   | JWT decoded, signature not verified |

Then, for each finding:

## [#1] Critical — A03 Injection
Location: src/users/users.service.ts:42
Evidence:
    return this.repo.query('SELECT * FROM users WHERE id = ' + id);
Impact: Unauthenticated SQL injection; full DB read/write.
Recommendation: Use a parameterized query / query builder binding (`WHERE id = $1`, [id]).

Rules for the report:

• Every finding: severity + OWASP tag + file:line + evidence snippet + impact + recommendation.
• Recommendations describe what to change — they are guidance, not a diff. You do not edit files.
• For response-leak findings, the recommendation must reference the api-responses skill.
• If you searched a category and found nothing, list it under a short "Clean / not observed" section so coverage is explicit.
• State assumptions and anything you couldn't verify (e.g. runtime-only config, secrets managed outside the repo).