OWASP Top 10 2024: What Changed and What You Need to Do

The OWASP Top 10 is the closest thing the application security world has to a canonical vulnerability taxonomy. For developers, architects, and security teams, it’s the baseline — the minimum standard every web application should be evaluated against.

But frameworks age. Attack patterns evolve. New vulnerability classes emerge. And every few years, OWASP updates the list to reflect where attackers are actually winning.

Here’s our practitioner-level breakdown of the significant shifts, what they mean in practice, and where your team should focus.

What OWASP Actually Is (and Isn’t)

Before diving in: the Top 10 is not a testing checklist. It’s a risk awareness document. The categories are intentionally broad — designed to highlight vulnerability classes, not individual bugs.

Used correctly, it should guide your threat modeling, inform your code review focus areas, and help you prioritize your assessment budget. Used incorrectly, it becomes a marketing label that security vendors slap on everything.

Keep that distinction in mind as you read.

---

The Categories That Matter Most Right Now

A01 — Broken Access Control (Staying at #1)

Access control failures have been the top finding in real-world assessments for years. The numbers back this up — in our own engagements, some form of broken access control appears in the majority of web application tests.

Why it’s so persistent: Access control logic is application-specific. No static analyzer fully understands your authorization model. Automated scanners are blind to business logic. Only manual testing — with context about what each user role should be able to access — reliably finds these issues.

The most common patterns we see:

• Insecure Direct Object References (IDOR) — changing an id parameter to access another user’s data
• Missing function-level access control — admin endpoints accessible without admin role
• JWT manipulation — modifying claims without signature verification
• CORS misconfigurations allowing credential-bearing cross-origin requests

What to do: Define your authorization matrix explicitly. Test every sensitive endpoint for role-based access. Review every place user-supplied IDs are used to retrieve records.

---

A02 — Cryptographic Failures

Previously called “Sensitive Data Exposure” — the rename is significant. The root cause is weak or missing cryptography, not just the resulting data exposure.

What this looks like in practice:

• Passwords stored with MD5 or SHA1 (still shockingly common in legacy systems)
• Sensitive data transmitted over HTTP
• Weak TLS configurations accepting deprecated cipher suites
• Hardcoded encryption keys in source code
• PII stored in server logs

The most important shift: Cryptographic failures increasingly intersect with API design. Data that’s properly encrypted at rest gets transmitted via API responses in cleartext to frontends that don’t need it. Always apply the principle of data minimization at the API layer.

---

A03 — Injection (Shifted Down, Still Critical)

SQL injection dropped from #1, but don’t mistake that for safety. SQLi is less common in greenfield applications using modern ORMs — but legacy systems, third-party integrations, and complex query builders are still riddled with it.

More importantly: the injection category has expanded. Server-Side Template Injection, LDAP injection, XPath injection, OS command injection, and NoSQL injection all fall here. As organizations move to document stores and adopt templating frameworks, the injection attack surface has shifted rather than shrunk.

Watch for: GraphQL injection is an underappreciated attack surface. GraphQL introspection combined with crafted queries can reveal schema details and bypass authorization logic in ways that traditional SQL injection mitigation doesn’t address.

---

A05 — Security Misconfiguration (Getting Worse)

Security misconfiguration is where cloud and containerization have made things significantly harder. The attack surface has expanded enormously — every managed service, every Kubernetes cluster, every IAM role is a potential misconfiguration.

In web applications specifically:

• Default credentials on admin panels (still the easiest win for attackers)
• Error messages exposing stack traces, internal paths, or framework versions
• Unnecessary features enabled — old APIs, debug endpoints, unused HTTP methods
• HTTP security headers missing or misconfigured (X-Frame-Options, CSP, HSTS)

In infrastructure: This category is where S3 bucket exposure, publicly accessible RDS snapshots, and overpermissioned IAM roles live. These aren’t application vulnerabilities — but they’re directly connected to your application’s risk posture.

---

A10 — Server-Side Request Forgery (New Focus)

SSRF moved to its own dedicated category because it’s become a primary vector for cloud environment compromise. When an attacker can make your server initiate HTTP requests to arbitrary destinations, the cloud metadata endpoint becomes the prize.

In AWS environments, http://169.254.169.254/latest/meta-data/ has led to complete credential compromise in countless incidents. In GCP and Azure, equivalent endpoints exist with similar impact.

Where SSRF hides: URL parsers, webhook destinations, image fetching functionality, PDF generators, XML parsers (via XXE), and any feature that fetches remote resources on behalf of a user.

---

What This Means for Your Remediation Roadmap

The Top 10 should influence how you prioritize, not just what you look for. Here’s how to translate it into action:

If you’re building new applications:

• Access control needs to be designed before it’s coded — not bolted on after
• Every API endpoint needs an explicit authorization decision
• Cryptography decisions should be made at the architecture stage, not the implementation stage

If you’re assessing existing applications:

• Broken access control and SSRF are the categories where manual testing has the highest signal — don’t rely on automated scanners here
• Cryptographic failures are often in the data model — look at what’s stored and how, not just how it’s transmitted

If you’re building a security program:

• Map your threat model to these categories annually
• Use the Top 10 to communicate risk to non-technical stakeholders — it’s a common vocabulary

---

The One Thing the Top 10 Won’t Tell You

The OWASP Top 10 is a vulnerability classification framework, not a business risk assessment. A critical IDOR in your admin panel that exposes all customer PII is not equivalent to a theoretical IDOR in a low-traffic internal tool.

Context is everything. The best security programs use the Top 10 as a vocabulary — but risk-prioritize based on data sensitivity, exploitability in your specific context, and real business impact.

That’s the difference between a compliance checklist and actual security.

---

Need help evaluating your application against the OWASP Top 10? Our Application Security engagements include comprehensive manual testing across all categories. Get in touch.