OWASP Top 10:2025 quick reference

Update: the OWASP Top 10 was revised for 2025. Use the Top 10:2025 labels and guidance in risk assessments and checklists.

References: OWASP Top 10:2025 — https://owasp.org/Top10/2025/

Workflow

Step 1: Define a validation layer with Zod (or equivalent)

Every external input must pass through a schema before touching business logic. Keep transformations explicit and log for review during development.

(Example omitted — use project-specific Zod schemas.)

Step 2: Harden HTTP headers

Apply strict header validation and common security headers. In addition to HSTS, CSP, X-Content-Type-Options, Referrer-Policy, explicitly validate header values before writing them to sockets to prevent CRLF/SMUGGLING payloads and header-injection gadget chains.

Practical rules:

• Reject header values containing CR or LF characters: if (/\r|\n/.test(value)) reject
• Normalize header names and canonicalize values before merging
• When merging user-supplied config into request headers, sanitize or drop unexpected keys

Practical egress-block sample (CI/build isolation):

• Cloud: add an egress rule that denies 169.254.169.254/32 from build subnets
• Linux iptables example (CI runner host): iptables -A OUTPUT -d 169.254.169.254 -j REJECT

Step 3: Sanitize output encoding

(Example omitted — use context-aware encoding helpers for HTML, attributes, JavaScript, CSS, and URLs.)

Step 4: Enforce parameterized queries

Use parameterized queries or ORM parameter binding for all database access. No string interpolation of user input into SQL.

(Example omitted — keep parameterized query advice and Supabase example.)

Step 5: Dependency & supply-chain management (detailed, updated)

Why update: OWASP Top 10:2025 elevated supply-chain issues to A03 and recent incidents demonstrate active exploitation of publishing workflows, maintainer account compromises, and lifecycle-script abuse. The March 31, 2026 Axios incident is a concrete example: malicious versions axios@1.14.1 and axios@0.30.4 were briefly published and contained a postinstall hook that pulled a hidden dependency (plain-crypto-js@4.2.1) which executed a cross-platform RAT during installation. The malicious releases were removed from npm within hours; see Snyk advisory for IOCs and indicators.

Concrete, operational controls (copy-paste checklist):

• Lockfiles & reproducible installs

  • Keep a single source-of-truth lockfile (package-lock.json / pnpm-lock.yaml / yarn.lock) in the repo.
  • CI: use reproducible installs and freeze behavior:
    • npm: npm ci --prefer-offline --no-audit --ignore-scripts
    • pnpm: pnpm install --frozen-lockfile --ignore-scripts
    • yarn: yarn install --immutable --ignore-scripts
  • Use --ignore-scripts when the production build does not require lifecycle scripts to run during package installation to reduce exposure to malicious postinstall hooks. Test builds in hermetic environments before enabling.

• SBOM (Software Bill of Materials)

  • Generate an SBOM for every build and attach it to release artifacts (CycloneDX or SPDX):
    • syft packages dir:. -o cyclonedx > sbom.cyclonedx.json

• SCA & scanning in CI

  • Run SCA tools in CI (Snyk, GitHub Dependabot, npm audit, pnpm audit) and gate merges on no new high/critical findings.
  • Example gate: snyk test || exit 1 or pnpm audit --level=high && exit 1.

• Verify package provenance and integrity

  • Where available, verify package signatures (in registries that support signing) or compare package tarball hashes before accepting new versions in gated builds.
  • Consider caching vetted tarballs in an internal registry (Artifactory, Nexus, Verdaccio) for production builds.

• Disallow or audit package lifecycle scripts in production builds

  • Avoid running untrusted lifecycle scripts during production builds; prefer building inside hermetic containers that do not execute package scripts.
  • If you must run lifecycle scripts, run them in an isolated step with restricted network access and short-lived credentials.

• Curated dependency allowlist & publishing hygiene

  • For critical builds, maintain an allowlist of approved packages and versions. Require 2FA for maintainer accounts that can publish critical packages.
  • Minimize publishing permissions and enforce separation-of-duty for release promotions (use separate signing and publishing CI jobs with different credentials).

• Artifact signing & integrity checks

  • Sign release artifacts and verify signatures during deployment to mitigate tampered releases (A08 mitigation).

• Lockfile auditing & CI runner hardening

  • Scan lockfiles for unexpected versions during release. Avoid running untrusted third-party workflows on privileged runners; isolate ephemeral runners and rotate tokens regularly.

• Incident response for supply-chain compromise (operational steps)

  1. Identify exposure: audit lockfiles and dependency trees to find where malicious versions were installed. Example commands:
     • npm ls axios@1.14.1 || true
     • npm ls axios@0.30.4 || true
     • grep -nE "axios[\"'@].*(1\\.14\\.1|0\\.30\\.4)" package-lock.json yarn.lock pnpm-lock.yaml || true
  2. Contain: suspend affected CI jobs and isolate ephemeral runners; rotate runner tokens and secrets.
  3. Eradicate: rebuild images from known-good lockfiles or pinned safe versions; prefer builds from signed artifacts or commit hashes predating the malicious publish.
  4. Rotate secrets that the compromised runner or build could access and revoke exposed credentials.
  5. Hunt for persistence: scan artifact storage, container registries, and deployed hosts for postinstall artifacts or network indicators.
  6. Notify stakeholders and publish IOCs internally (hashes, C2 domains) to speed detection — vendors like Snyk publish IOCs in advisories.

References: Snyk advisory on Axios compromise (SNYK-JS-AXIOS-15850650, Mar 31, 2026) — https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/

Header-sanitization & prototype-pollution mitigation (new)

Why: GitHub and Snyk advisories described gadget chains where un-sanitized header values and prototype pollution in third-party parsers can escalate into metadata exfiltration (IMDS / cloud metadata) and similar attacks. Operational mitigations:

• Avoid compromised Axios releases (e.g., axios@1.14.1 and axios@0.30.4). Immediate remediation options:
  • Pin to a known-safe version or upgrade to a release explicitly marked fixed by the Axios project. Verify the project's official advisory and cross-check with Snyk/GHSA/NVD before selecting the upgrade target.
  • If you rely on transitive dependencies, scan lockfiles for plain-crypto-js@4.2.1 (the malicious dependency used in the Axios incident) and other unexpected packages.
• Apply a header validator before writing headers to sockets (reject CR/LF characters and unexpected header names).
• Prevent prototype pollution sources: keep parsers and CLI libraries updated (e.g., qs, minimist) and adopt runtime checks that reject unexpected properties on merged configs.
• Restrict server-side code from making requests to sensitive IP ranges (169.254.169.254 for AWS metadata) unless explicitly required. Add egress firewall rules or platform-level allowlists; for build/CI runners, block IMDS access where not needed.

Example header-sanitization pseudo-fix (conceptual):

// when setting headers Object.entries(headers).forEach(([k,v]) => { if (typeof v === 'string' && /[\r\n]/.test(v)) throw new Error('Invalid header value'); // canonicalize and whitelist header names here });

Reference: GitHub Advisory — Axios header-injection / metadata exfiltration (GHSA-fvcv-3m26-pcqx / CVE-2026-40175) — https://github.com/advisories/GHSA-fvcv-3m26-pcqx

Note: register CVE details can be checked at NVD (CVE-2026-40175) — https://nvd.nist.gov/vuln/detail/CVE-2026-40175

Step 6: Secure-by-design & threat modeling

• Follow OWASP A06: Insecure Design: create abuse stories for each feature and make them part of acceptance criteria.
• Require security review for new third-party integrations and any change that crosses trust boundaries.

Step 7: Runtime protections

• Enforce least privilege for service identities and database roles.
• Use network egress allowlists for backend services and block outbound access from build runners where possible.
• Rotate keys and use short-lived credentials.

Examples and defensive checks (concrete)

• Lockfile check (quick):
  • npm ci --ignore-scripts && npm ls axios@1.14.1 || npm ls axios@0.30.4 || true
• SBOM extraction (example):
  • syft packages dir:. -o cyclonedx > sbom.cyclonedx.json
• Detect suspicious metadata egress (example):
  • Search logs and egress flows for requests to 169.254.169.254 or unusual IMDS token creation events
  • grep -R "169.254.169.254" /var/log || true

Dev-server and template engine hardening

Recent advisories emphasize that developer tooling and template engines can expose sensitive files when misconfigured or when APIs that accept filenames are used with attacker-controlled input.

• Template engines: do not pass untrusted filenames to file-loading APIs. For example, LiquidJS published a GitHub Security Advisory where renderFile() / parseFile() accepted absolute paths and bypassed configured root, allowing arbitrary file reads (patched in 10.25.5). If you use template engines, ensure:

  • You pin patched versions (e.g., upgrade liquidjs to >= 10.25.5).
  • You validate and canonicalize template path inputs and reject absolute or parent-traversal paths.
  • Use regression tests that assert a configured root rejects external absolute paths.
  • Reference: GitHub Advisory — LiquidJS renderFile/parseFile bypass — https://github.com/advisories/GHSA-v273-448j-v4qj

• Dev servers: never expose dev servers (Vite, webpack dev server) to public or CI-accessible CIDRs. Run production builds in CI with production mode flags and avoid running dev-only features in CI or on shared runners.

Decision tree (concise)

• User input arrives → validate with Zod schema
• Rendering user content → apply context-appropriate output encoding
• Storing passwords → use argon2id or bcrypt (cost >= 12)
• Accessing data → enforce row-level security + server-side auth checks
• Third-party dependency → pin version, run SCA, generate SBOM, and fail CI on high severity
• Sensitive config → environment variable, not committed to repo

Edge cases and gotchas

• Double encoding — track encoding state to avoid double-encoding user data
• Zod transforms — .transform() runs after validation; log during development
• CSP vs inline scripts — use nonces or external scripts to keep CSP strict
• Rate limiter bypass — do not trust X-Forwarded-For; use platform-provided trusted headers
• Lockfile drift — always use frozen lockfile behavior in CI
• RLS defaults — platform databases like Supabase do not enable RLS by default; enable and test
• JWT expiry mismatches — use short-lived access tokens and separate refresh flow
• Parser differentials, HTTP/2 CONNECT, cache poisoning chains — PortSwigger research highlights new techniques to consider when canonicalizing inputs and designing caching/edge rules (see PortSwigger Top 10 web hacking techniques of 2025)
  • Reference: https://portswigger.net/research/top-10-web-hacking-techniques-of-2025

Evaluation criteria

• Typed validation for all external input
• No raw SQL string interpolation
• Security headers applied (HSTS, CSP, X-Content-Type-Options)
• Passwords hashed with argon2id or bcrypt (cost >= 12)
• RLS enabled on all user-data tables
• CI fails on high/critical SCA alerts
• SBOM generated and attached to releases
• Postinstall lifecycle scripts audited or disabled in production builds
• Rate limiting applied to auth and write endpoints
• Secrets not stored in code
• Error responses sanitized
• Security logging for auth failures and permission denials

Dependency-audit workflow (concrete)

1. Developer opens PR with new dependency. CI generates SBOM and runs SCA.
2. CI uses reproducible installs (npm ci / pnpm install --frozen-lockfile) and snyk test or equivalent.
3. Fail the pipeline on high/critical findings and post actionable PR remediation.
4. On merge, sign artifacts and attach SBOM to the release.
5. Weekly full dependency sweep and automated PRs from Dependabot/Renovate for routine updates.

Incident response quick checklist (supply-chain & header-injection focus)

• IOCs (example from Axios incident): collect package names, versions, hashes, and C2 domains/IPs published by vendor advisories. Known IoCs from the Snyk advisory: axios@1.14.1, axios@0.30.4, plain-crypto-js@4.2.1, C2 domain sfrclak[.]com, observed IP 142.11.206.73. (See Snyk advisory for full IOCs.)
• Contain: suspend affected CI jobs, isolate runners, revoke tokens.
• Metadata / header-injection specific actions:
  • Search for suspicious header values in logs (CRLF sequences, unexpected x-amz-target values).
  • Audit egress to 169.254.169.254 in logs and network flows; block it from build/CI networks where possible.
  • If prototype pollution is suspected, identify and patch the vulnerable parser and rotate credentials that could be exfiltrated.
• Eradicate: rebuild using known-good lockfiles or signed artifacts; rotate secrets.
• Recover: redeploy signed artifacts, validate via SBOM.
• Post-mortem: record timeline, root cause, and update processes.

Research-backed changes in this revision

• Added concrete Snyk advisory reference (SNYK-JS-AXIOS-15850650) with affected versions (axios@1.14.1 and axios@0.30.4), malicious transitive dependency plain-crypto-js@4.2.1, and example C2 indicators published by Snyk.
• Tightened guidance around header-sanitization with explicit advice to block IMDS egress from CI/build runners and to validate header contents before writing to sockets.
• Expanded supply-chain operational controls and incident playbook using Snyk and GitHub advisory details as models for immediate actions and IOCs. Added NVD CVE reference for cross-checking (CVE-2026-40175).
• Preserved prior LiquidJS template-engine hardening and added concrete test/patch advice for template path validation.
• Incorporated PortSwigger Top 10:2025 research pointers on parser differentials, HTTP/2 CONNECT, and cache-poisoning chains for edge and CDN rule design.

Fresh signals used for this refresh

• Snyk: Axios npm package compromised (SNYK-JS-AXIOS-15850650, Mar 31, 2026) — supply-chain incident and IOCs
  • https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/
• OWASP Top 10:2025 — updated taxonomy including A03: Software Supply Chain Failures
  • https://owasp.org/Top10/2025/
• PortSwigger Research — Top 10 web hacking techniques of 2025
  • https://portswigger.net/research/top-10-web-hacking-techniques-of-2025
• GitHub Advisories: Axios header-injection / metadata exfiltration (GHSA-fvcv-3m26-pcqx) and LiquidJS renderFile path bypass (GHSA-v273-448j-v4qj)
  • https://github.com/advisories/GHSA-fvcv-3m26-pcqx
  • https://github.com/advisories/GHSA-v273-448j-v4qj
• NVD: CVE-2026-40175
  • https://nvd.nist.gov/vuln/detail/CVE-2026-40175

Next edits

• Add runnable incident response scripts to automate lockfile scanning and SBOM extraction for common package managers.
• Add a CI hardening checklist for ephemeral runner security and egress firewall rules.

Experiments / future work

• Integrate automated SBOM comparison checks between builds to detect silent changes
• Simulate supply-chain incidents in tabletop exercises and publish scripted playbooks
• Prototype CI checks that automatically disable lifecycle scripts for production builds unless explicitly whitelisted