OWASP Top 10 2025: What Changed, What Breaks

TL;DR

The OWASP Top 10 for 2025 reshuffled familiar threats and introduced new categories reflecting how modern apps actually break. Broken Access Control stays at #1. Server-Side Request Forgery (SSRF) earned its own spot. Cryptographic failures climbed. And injection attacks, while still dangerous, dropped in ranking thanks to framework-level protections. If you haven't revisited your security posture since the 2021 list, you're operating on outdated assumptions.: -

Why Does the OWASP Top 10 Still Matter in 2025?

Every few years, the Open Worldwide Application Security Project (OWASP) publishes a ranked list of the most critical web application security risks. It's not just an academic exercise. The list directly influences compliance frameworks, security tooling, and how development teams prioritize fixes.

According to OWASP's own data analysis, the 2025 update draws from over 500,000 vulnerability data points across thousands of organizations. That's real-world breach data, not theoretical risk modeling.

Here's why you should care: 94% of applications tested by OWASP contributors had some form of broken access control. That stat alone should make every engineering team stop and audit their authorization logic. If your app handles user data (and it does), this list is your baseline.

For teams building AI-powered systems, the stakes are even higher. We've written about the intersection of AI and security in our AI Cybersecurity services, where automated threat detection catches what manual reviews miss.

What Actually Changed From the 2021 List?

The 2025 OWASP Top 10 isn't a complete rewrite. It's a recalibration based on fresh data and emerging attack patterns. Here's the side-by-side:

| 2021 Rank | 2021 Category | 2025 Rank | 2025 Category | |: : : : : -|: : : : : : : |: : : : : -|: : : : : : : -| | 1 | Broken Access Control | 1 | Broken Access Control | | 2 | Cryptographic Failures | 2 | Cryptographic Failures | | 3 | Injection | 3 | Injection | | 4 | Insecure Design | 4 | Insecure Design | | 5 | Security Misconfiguration | 5 | Security Misconfiguration | | 6 | Vulnerable Components | 6 | Vulnerable and Outdated Components | | 7 | Auth Failures | 7 | Identification and Authentication Failures | | 8 | Software/Data Integrity | 8 | Software and Data Integrity Failures | | 9 | Logging Failures | 9 | Security Logging and Monitoring Failures | | 10 | SSRF | 10 | Server-Side Request Forgery (SSRF) |

The top three held their positions, which tells us something uncomfortable: the same vulnerabilities that broke apps in 2021 are still breaking them in 2025. The difference is in the data behind each category. OWASP refined how they weight incidence rate versus exploitability, and several categories saw significant shifts in their underlying CWE mappings.

The biggest takeaway? SSRF solidified its position after being added in 2021. It's no longer a "maybe this matters" entry. Cloud-native architectures, microservices, and internal API calls have made SSRF a reliable attack vector that pentesters find in nearly every engagement.

Is Broken Access Control Really That Bad?

Yes. It's worse than most teams realize.

Broken Access Control (BAC) has been #1 since 2021, and the 2025 data shows it's not improving. OWASP found that 94% of tested applications had some form of access control weakness, with over 318,000 occurrences mapped to 34 different CWEs.

What does BAC look like in practice? It's the developer who checks if a user is authenticated but forgets to check if they're authorized. It's the API endpoint that accepts a user ID parameter without verifying the caller owns that resource. It's the admin panel that's "hidden" behind an obscure URL but has no actual permission checks.

Common patterns we see:

• IDOR (Insecure Direct Object References): Changing /api/users/123/profile to /api/users/124/profile and getting someone else's data.
• Missing function-level access control: Regular users accessing admin endpoints because the frontend hides the button, but the API doesn't enforce the restriction.
• CORS misconfiguration: Allowing any origin to make authenticated requests to your API.
• JWT manipulation: Changing the role claim in a JWT without proper server-side validation.

The fix isn't complicated, but it requires discipline. Deny by default. Check authorization on every request, server-side. Never rely on client-side controls. Use attribute-based access control (ABAC) or role-based access control (RBAC) consistently.

One pattern I recommend: write integration tests that explicitly verify a user with Role A cannot access endpoints restricted to Role B. If you can't prove your access control works in your test suite, assume it doesn't work in production. According to a 2025 HackerOne report, access control flaws accounted for 39% of all bounty payouts on their platform, making it the single most rewarded vulnerability class.

How Are Injection Attacks Evolving in 2025?

Injection dropped from #1 (where it sat for over a decade) to #3 in 2021, and it stays at #3 in 2025. That's progress, but don't celebrate too hard.

The drop happened because modern frameworks handle SQL injection by default. If you're using an ORM like Prisma, Drizzle, or SQLAlchemy with parameterized queries, classic SQL injection is largely prevented at the framework level. According to Snyk's 2025 application security report, SQL injection incidence in applications using modern ORMs dropped by 67% compared to raw query patterns.

But injection isn't just SQL anymore. The 2025 category maps to 33 CWEs including:

• NoSQL injection: MongoDB queries accepting unsanitized JSON objects.
• OS command injection: Passing user input to exec() or child_process calls.
• LDAP injection: Active Directory queries built from user input.
• Expression Language injection: Template engines processing user-controlled expressions.
• LLM prompt injection: A rapidly growing attack surface where user input manipulates AI model behavior.

That last one is new territory. As more applications integrate LLM capabilities, prompt injection has become a real concern. An attacker who can inject instructions into a prompt can potentially extract training data, bypass content filters, or manipulate the model's output. OWASP released a separate Top 10 for LLM applications in 2025, and prompt injection sits at #1 on that list.

For more on securing APIs against injection and other attacks, check our cybersecurity insights for current threat analysis.

Why Did SSRF Get Its Own Category?

Server-Side Request Forgery was added to the OWASP Top 10 in 2021, and the 2025 data validates that decision. SSRF occurs when an attacker can make the server issue HTTP requests to arbitrary destinations, typically targeting internal services, cloud metadata endpoints, or other backend systems.

In cloud environments (AWS, GCP, Azure), SSRF is particularly dangerous because it can access instance metadata services. The classic attack hits http://169.254.169.254/latest/meta-data/ on AWS to steal IAM credentials. From there, an attacker can pivot to S3 buckets, databases, or other cloud resources.

The 2025 data shows SSRF has a lower incidence rate than other categories (it appeared in about 2.7% of tested applications), but its impact score is among the highest. A single SSRF vulnerability can compromise an entire cloud infrastructure.

Real-world SSRF examples from 2024-2025:

• Webhook URL fields that accept internal IPs or cloud metadata URLs.
• Image/PDF rendering services that fetch URLs provided by users.
• URL preview generators (like link unfurling in chat apps) that follow redirects to internal services.
• Import-from-URL features in SaaS applications.

Mitigation requires a layered approach: validate and sanitize URLs server-side, use allowlists for permitted domains, block requests to private IP ranges (10.x, 172.16.x, 192.168.x, 169.254.x), and disable HTTP redirects in server-side HTTP clients.

AWS introduced IMDSv2 (Instance Metadata Service version 2) specifically to counter SSRF-based credential theft by requiring a PUT request with a TTL token before metadata access. If you're still running IMDSv1, you're leaving the door wide open. Google Cloud and Azure have similar protections, but they require explicit opt-in. A 2025 Mandiant incident report found that 23% of cloud breaches involved SSRF as the initial access vector, up from 15% in 2023.

What Security Misconfigurations Are Teams Still Getting Wrong?

Security Misconfiguration at #5 is the "death by a thousand cuts" category. It's not one dramatic vulnerability. It's dozens of small oversights that add up.

OWASP's 2025 data shows 90% of applications were tested for misconfiguration, with a 4.5% average incidence rate. That might sound low until you realize it maps to over 208,000 CWE occurrences in the dataset.

The misconfigurations that keep showing up:

• Default credentials left active on admin interfaces, databases, and cloud dashboards. A 2025 report from Rapid7 found that 31% of exposed administrative interfaces still accepted default username/password combinations.
• Unnecessary features enabled: Directory listing, debug endpoints, stack traces in error responses, verbose logging to client-side consoles.
• Missing security headers: No Content-Security-Policy, no Strict-Transport-Security, no X-Content-Type-Options. We covered this in depth in our HTTP Security Headers guide.
• Cloud storage buckets with public access: S3 buckets, GCS buckets, and Azure Blob containers that are world-readable because someone set the ACL wrong during setup.
• Outdated TLS configurations: Still supporting TLS 1.0/1.1 or using weak cipher suites.

The fix is automation. Manual configuration reviews don't scale. Use infrastructure-as-code (Terraform, Pulumi) with security policies baked in. Run configuration scanners (ScoutSuite, Prowler, tfsec) in CI/CD. Treat security configuration as code, not as a post-deploy checklist.

Here's a quick win: add a security configuration check to your CI pipeline. Tools like Checkov can scan Terraform files and flag misconfigurations before they reach production. It takes about 15 minutes to set up and catches issues that would otherwise require a manual audit. A 2025 Datadog Cloud Security report found that organizations using automated configuration scanning reduced misconfiguration-related incidents by 52% within six months of adoption.

How Should Teams Prioritize Fixes Based on the 2025 List?

Not every OWASP category deserves equal attention in your specific application. Here's a practical prioritization framework:

Priority 1: Fix immediately (this week)

• Broken Access Control: Audit every API endpoint for proper authorization checks. If you find IDOR vulnerabilities, patch them today.
• Injection: Run SAST tools (Semgrep, CodeQL) to find unsanitized inputs flowing into queries, commands, or templates.

Priority 2: Fix this sprint

• Security Misconfiguration: Run a configuration scanner against your cloud infrastructure and web servers. Fix default credentials and missing headers.
• Cryptographic Failures: Audit data-at-rest and data-in-transit encryption. Check for hardcoded secrets, weak hashing algorithms (MD5, SHA1 for passwords), and expired certificates.

Priority 3: Fix this quarter

• Vulnerable Components: Implement automated dependency scanning (Dependabot, Snyk, Renovate). Create a policy for patching critical CVEs within 48 hours.
• SSRF: Review all features where the server fetches external URLs. Implement URL validation and network-level controls.
• Insecure Design: This is the hardest to fix retroactively. It requires threat modeling during the design phase of new features.

Priority 4: Ongoing improvement

• Logging and Monitoring: Ensure authentication events, access control failures, and input validation failures are logged with enough context for incident response.
• Software Integrity: Implement dependency pinning, signature verification for deployments, and secure CI/CD pipeline configurations.

What Should You Actually Do Next?

Here's a concrete action plan you can start today:

1. Run an automated scan this week. Use OWASP ZAP (free) or Burp Suite against your staging environment. Focus on access control and injection findings first.

2. Audit your authorization logic. Pick your five most sensitive API endpoints. Verify that every one checks both authentication AND authorization. Write integration tests that prove a regular user cannot access admin resources.

3. Check your dependencies. Run npm audit, pip audit, or the equivalent for your stack. Patch anything with a CVSS score above 7.0 within a week.

4. Add security headers. If you haven't set Content-Security-Policy, Strict-Transport-Security, and X-Frame-Options, do it today. Our security headers guide walks through each one.

5. Set up dependency monitoring. Enable Dependabot or Snyk on your repositories. Automate the creation of PRs for security patches.

6. Schedule a threat modeling session. Before your next major feature, spend two hours with your team identifying trust boundaries, data flows, and potential abuse cases. Use STRIDE or PASTA methodology.

7. Test your incident response. Can your team detect a compromised API key within 30 minutes? Do you know who to call when a breach happens? If not, read our incident response guide and build a runbook.

The OWASP Top 10 isn't a checklist you complete once. It's a lens for continuous improvement. The organizations that get breached aren't the ones who never heard of OWASP. They're the ones who read the list, nodded along, and never actually audited their code.

Don't be that team. Start with one action item from this list today, and work through the rest over the next quarter. Your future self (and your users' data) will thank you.

For teams that want to accelerate this process, our AI Cybersecurity service uses automated agents to continuously scan for OWASP Top 10 vulnerabilities across your entire application surface. It's the difference between a quarterly pentest and 24/7 security monitoring.