OWASP Top 10 Reference
A plain-English reference for the OWASP Top 10 (2025) web application security risks — what each one is, the damage it can do, and the fixes that matter.
The OWASP Top 10 (2025) — the web application security risks that matter most. Each entry names the attack, why it hurts, and the fixes that actually move the needle.
A01:2025 Broken Access Control
Why it hurts: Access controls not enforced server-side. Users read or modify others’ data, or hit admin functions they shouldn’t.
Fix: Enforce authorization on every request, deny-by-default, object-level ownership checks, no IDs you can trust from the client, rate-limit and audit sensitive actions.
A02:2025 Cryptographic Failures
Why it hurts: Sensitive data transmitted or stored without encryption, or with weak/broken algorithms.
Fix: Encrypt data in transit and at rest with modern algorithms (TLS 1.2+, AES-256), hash passwords with Argon2/bcrypt, don’t roll your own crypto.
A03:2025 Injection
Why it hurts: Untrusted input concatenated into SQL, shell, LDAP or template commands — attackers run their own queries or code.
Fix: Parameterized queries, prepared statements, allowlists for dynamic input, escape output, treat all input as untrusted.
A04:2025 Insecure Design
Why it hurts: The architecture itself has no security controls — missing threat modeling, trust boundaries, or rate limits baked into the design.
Fix: Threat-model before building, model security requirements up front, budget for controls (rate limits, quotas, replay protection) in the design, not as patches.
A05:2025 Security Misconfiguration
Why it hurts: Default credentials, verbose stack traces, unhardened servers, open cloud storage, missing security headers.
Fix: Automated configuration scans, minimal/least-privilege configs, disable default accounts, never ship defaults, enforce security headers.
A06:2025 Vulnerable and Outdated Components
Why it hurts: Known-vulnerable libraries and runtimes in production, often months behind the patched release.
Fix: Track dependencies (software bill of materials), patch automatically, remove unused components, watch feeds for CVE disclosures.
A07:2025 Identification and Authentication Failures
Why it hurts: Weak login flows, predictable sessions, missing multi-factor — credentials get stolen or sessions hijacked.
Fix: Multi-factor authentication, strong password policies, secure session lifecycle (rotate, invalidate on logout), lockout and brute-force protection.
A08:2025 Software and Data Integrity Failures
Why it hurts: Code or data accepted without verifying its source — malicious updates, CI/CD tampering, unsafe deserialization.
Fix: Sign code and data, verify integrity at deploy, pin dependencies, only deserialize trusted streams, secure the build pipeline.
A09:2025 Logging and Monitoring Failures
Why it hurts: No visibility — attacks run for weeks undetected because events aren’t logged, alerting is absent, and incident response is manual.
Fix: Log authentication, access and admin actions with timestamps; alert on anomalies; protect logs from tampering; practice incident response.
A10:2025 Server-Side Request Forgery (SSRF)
Why it hurts: The server fetches a URL the attacker supplied, reaching internal services, cloud metadata, or the local network.
Fix: Validate and allowlist destinations, block private/link-local ranges, use deny-by-default egress, disable redirects, require authentication for outbound fetches.
Source: OWASP Foundation — owasp.org/www-project-top-ten
How to use this reference
This is a reference to the OWASP Top 10 (2025). Each entry explains the attack, why it hurts, and the fixes that matter. Use it as a checklist when reviewing or threat-modeling your own web app.
FAQ
What is the OWASP Top 10?
A periodically updated consensus list of the most critical web application security risks, produced by the OWASP Foundation from real-world data. It’s the de-facto starting checklist for web app security.
How often is it updated?
It’s revised roughly every three to four years; the 2025 edition replaced the 2021 list. Check you’re reviewing the current version rather than an old one.
Is it a formal compliance standard?
No, but it’s widely referenced by audits and frameworks. Treat it as a prioritized baseline, not an exhaustive list of every possible vulnerability.
How should I use it?
Walk through each risk against your app while you build and review: validate you have server-side access control (A01), modern crypto and hashing (A02), parameterized queries (A03), and logging/alerting (A09).