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.

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

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.

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 compromise (Snyk advisory SNYK-JS-AXIOS-15850650) is a concrete example where attacker-controlled publishes included a malicious postinstall dependency (plain-crypto-js@4.2.1) that executed a cross-platform RAT during installation. (See Snyk advisory for IOCs and remediation guidance.)

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 and enforce SSO for org-level publishing accounts.
  • 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.

• Monitoring & alerting

  • Subscribe to vendor advisories (Snyk, GitHub Security Advisories, NVD) and add automated alerts into your security backlog for immediate triage of supply-chain disclosures.

• Container image management (note)

  • Snyk announced Container Registry Sync GA for automated image management and runtime intelligence to help scale container security and enforce known-good images in registries.

• AI/agent supply-chain surfaces

  • Recent Snyk analysis of AI/model supply-chain incidents highlights the need to map the "AI blast radius" for connected models and agent workflows in addition to traditional package dependencies. Track model sources and deployed agent integrations in your SBOM/asset inventory.

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) and similar attacks. Operational mitigations are concrete and low-cost.

• 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

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

• 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.

Runnable incident-response helper (copy-paste)

quick scan for affected axios versions (npm/yarn/pnpm)

usage: ./scan-axios.sh

#!/usr/bin/env bash set -euo pipefail repos=(.) for d in "${repos[@]}"; do echo "Scanning $d" pushd "$d" > /dev/null || continue npm ci --ignore-scripts >/dev/null 2>&1 || true npm ls axios@1.14.1 || 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 syft packages dir:. -o cyclonedx > sbom.cyclonedx.json || true popd > /dev/null done

Note: run this from a hermetic, offline build worker and rotate credentials before and after running if you suspect compromise.

Dev-server and template engine hardening (repeated guidance)

• Pin patched template engines and validate canonical paths.
• Do not expose dev servers to CI or public networks.

Research-backed changes in this revision

• Formalized operational supply-chain mitigations and included Snyk IOCs and practical CI commands for rapid triage (Snyk advisory SNYK-JS-AXIOS-15850650, Mar 31, 2026).
• Added explicit header-sanitization guidance and linked the GitHub advisory/CVE that shows how prototype pollution + unsanitized headers can lead to IMDS compromise (GHSA-fvcv-3m26-pcqx / CVE-2026-40175).
• Incorporated PortSwigger Top 10:2025 pointers on parser differentials, HTTP/2 CONNECT, and cache-poisoning chains as edge considerations (PortSwigger Research, Feb 5, 2026).
• Noted Snyk product signals: Snyk Secrets for in-commit secret detection and Container Registry Sync GA for image management (Snyk Blog, Apr 2026) to encourage integrating secrets detection and image vetting into CI.

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/
• GitHub Advisory: Axios header-injection / metadata exfiltration (GHSA-fvcv-3m26-pcqx / CVE-2026-40175)
  • https://github.com/advisories/GHSA-fvcv-3m26-pcqx
• 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
• Snyk Blog: Hardcoding Security into Every Commit (Snyk Secrets) and Container Registry Sync GA (Apr 2026)
  • https://snyk.io/blog/future-snyk-secrets/
  • https://snyk.io/blog/scale-container-security-effortlessly/

Next edits

• Add runnable incident response scripts to automate lockfile scanning and SBOM extraction for common package managers (starter script added above).
• 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