OWASP Top 10 2025: what changed and what to fix first
The 2025 OWASP Top 10 reshuffled the list — Software Supply Chain entered, and Broken Access Control still leads. A practical guide to addressing each.
The OWASP Top 10 is the most-cited list of web application security risks, refreshed every three to four years from contributed and bug-bounty data. The 2025 release, finalized in early 2025, keeps Broken Access Control at A01 — it appeared in 94 percent of contributed application portfolios. A02 Cryptographic Failures and A03 Injection follow. The newest entry is A10 Software Supply Chain Failures, replacing the older Software and Data Integrity Failures category and reflecting the rise of attacks on packages and CI pipelines.
Each entry maps to specific Common Weakness Enumeration (CWE) families. A01 covers CWE-22 path traversal, CWE-285 improper authorization, and CWE-639 IDOR. The most impactful single fix is to default to deny in your authorization layer and apply allowlist checks on every privileged action, with object ownership checks on every record. Frameworks like Spring Security, Django Guardian, and Casbin make this declarative; rolling your own is the fastest road to A01 findings.
A02 Cryptographic Failures captures hardcoded keys, MD5 password hashing, and missing TLS. Use Argon2id with a 64 MB memory cost and three iterations for password storage, AES-256-GCM for symmetric encryption with a fresh nonce per message, and ECDH-P256 or X25519 for key exchange. Modern TLS means TLS 1.3 with secrets rotated through automated certificate management — Let's Encrypt or AWS ACM are sufficient for most deployments.
A03 Injection still covers SQL injection alongside command injection and LDAP injection. Use parameterized queries via your ORM, never string concatenation. For supply chain, A10, pin direct dependencies, generate an SBOM in CycloneDX or SPDX format on every build, sign artifacts with Sigstore cosign, and run npm audit, pip-audit, or osv-scanner in CI. Treat the GitHub Dependabot alerts as P2 tickets with a service-level agreement, not a wishlist.
Related reading
What is penetration testing and how to scope one
A penetration test is not a vulnerability scan — it is targeted exploitation by a human, and how you scope it determines whether the report is useful.
Black-box vs white-box penetration testing: which to choose
Black-box mirrors a real attacker but burns budget on reconnaissance — white-box finds more bugs in the same hours. Here is when each makes sense.
Vulnerability assessment vs penetration test: pick the right tool
A vulnerability scan is a list. A pentest is a story. They serve different purposes — buying the wrong one wastes money and gives false assurance.