The OWASP Top 10 (2025): 10 Ways Developers Are Handing Attackers the Keys

Every major breach you've read about in the last five years?

It was probably on this list.

The OWASP Top 10 is updated every few years. It is not theory. It is a leaderboard of the most exploited vulnerabilities in production systems, right now, in companies with real engineering teams and real security budgets.

Here are all 10. With receipts.

#1 — Broken Access Control

Still number one. Has been number one since 2021.

This is what happens when your server trusts the client to tell it what data to fetch — and never checks whether that user actually owns it.

The attack is almost embarrassingly simple. You change a number in a URL or a request body. user_id=1001 becomes user_id=1002. Server returns someone else's data. No hacking. Just counting.

Real world: In 2022, Optus — Australia's second-largest telco — exposed nearly 10 million customer records through an unauthenticated API endpoint. No authentication required. You just had to know the URL existed. By the time they shut it down, the attacker had already enumerated and downloaded records on a massive scale.
The April 2026 - Lovable breach is a perfect, modern example of Broken Object Level Authorization (BOLA).In this real-world incident, the AI-powered app-building platform Lovable exposed sensitive project data—including source code, internal AI reasoning logs, database credentials, and production customer information.The attack flow highlights exactly how a modern BOLA vulnerability operates:

Mitigate with: server-side authorization checks on every request, SAST, DAST, and regular pen testing.

#2 — Security Misconfiguration

Your application code can be perfect. Your infrastructure will still betray you.

This one is almost always an infrastructure problem, not a code problem. Public S3 buckets. Default credentials left unchanged. Verbose error messages exposing stack traces to end users. Debug endpoints left alive in production.

Real world: In 2023, PwC Nigeria had passports and personal addresses of bootcamp participants leaked from a misconfigured S3 bucket. The same year, Capita — a major UK government outsourcing firm — had council resident data exposed the same way. Not because someone hacked them. Because someone clicked the wrong permission setting.

Datadog reported that as of 2024, 1.48% of all AWS S3 buckets were effectively public. That sounds small until you realize there are hundreds of billions of S3 objects out there.

Mitigate with: IaC scanning, CSPM tools, and the radical idea of auditing your cloud permissions more than once a year.

#3 — Software & Supply Chain Failures

This one has evolved. It used to be called "outdated components." The 2025 edition is scarier.

It's not just about forgetting to patch. It's about trusting software you didn't write, can't audit, and don't fully understand — because it's open-source, or it came from a VS Code extension, or it's a transient dependency six layers deep in your package tree.

Real world: In March 2024, a developer named "Jia Tan" — who had spent two years quietly contributing to the XZ Utils open-source compression library — pushed a malicious backdoor into versions 5.6.0 and 5.6.1. The CVSS score was a perfect 10.0. It targeted OpenSSH authentication on Linux systems. It was only caught because a Microsoft engineer noticed an unexplained performance drop in a pre-release Debian build. That was luck. Not process.

The SolarWinds attack in 2020 hit 18,000+ organizations — including US government departments — via a compromised software build pipeline. The attackers had access for months before anyone noticed.

Mitigate with: SCA tools, dependency auditing, pinned package versions, and signed CI/CD pipelines.

#4 — Cryptographic Failures

Using encryption is not enough. Using the right encryption is the actual requirement.

MD5 is not encryption. SHA-1 without salting is not protection. Storing sensitive data in plaintext because "it's an internal database" is a decision someone will regret personally.

Real world: In 2012, LinkedIn was breached. 6.5 million password hashes were leaked. They used unsalted SHA-1. Crackers broke over 60% of them almost immediately. The full scale of the breach wasn't revealed until 2016 — 117 million accounts. The passwords were essentially readable because the underlying cryptographic choices were made by people who never expected the database to leak.

Security researchers can calculate approximately 20 billion MD5 hashes per second on modern hardware. That "encrypted" database is not encrypted. It's a waiting room.

Mitigate with: bcrypt, scrypt, or Argon2 for passwords. TLS everywhere. SAST to catch weak algorithm usage.

#5 — Injection

This one has been on the OWASP list since the beginning. And it keeps showing up.

The concept is deceptively simple: user input that gets treated as executable code. SQL injection. Command injection. LDAP injection. The application trusts the data, the database doesn't know better, and now the attacker is running arbitrary queries on your production database.

Real world: In May 2023, the Cl0p ransomware group exploited a zero-day SQL injection vulnerability in MOVEit Transfer — a widely used enterprise file transfer tool. CVE-2023-34362. They had been testing this vulnerability since 2021. When they finally pulled the trigger, they hit thousands of organizations in days. Amazon confirmed that data on over 2 million employees was exposed. The BBC, British Airways, and multiple US government agencies were among the victims.

All of this because untrusted input reached a database query without sanitization.

Mitigate with: prepared statements, parameterized queries, input escaping, and SAST/DAST scanning.

#6 — Insecure Design

This is the uncomfortable one.

The other nine vulnerabilities on this list are implementation problems. This one is a thinking problem. Logic flaws baked into how a system was designed, before a single line of code was written.

You can't patch your way out of insecure design. It requires going back to the architecture.

Real world: In September 2022, an 18-year-old hacker got into Uber's internal systems — including Slack, AWS, and Google Workspace — without a single sophisticated exploit. He bought a contractor's stolen credentials online, then bombarded that contractor's phone with MFA push notifications. Forty notifications in thirty minutes. The contractor, exhausted, approved one. The attacker then impersonated Uber IT support on WhatsApp to explain what was happening. Inside, he found PowerShell scripts with hardcoded admin credentials.

No SQL injection. No zero-day. A design that assumed MFA push notifications were sufficient and that human fatigue would never become the attack surface.

Mitigate with: threat modeling (STRIDE), security design reviews, and treating human behavior as part of the attack surface, not an afterthought.

#7 — Authentication Failures

Credential stuffing. Default passwords. Broken session management. All of these live here.

The problem is almost never that authentication is too hard to implement. The problem is that teams roll their own authentication instead of using trusted providers — and discover later how many edge cases they missed.

Real world: The T-Mobile breach of 2023 traced back to API endpoints that didn't verify the requesting customer matched the account being queried. Change the account identifier. Get someone else's data. Authentication was present. Authorization was absent. The distinction matters enormously.

Default credentials remain one of the most reliable attack paths against enterprise infrastructure. Not because organizations don't know better. Because nobody checked.

Mitigate with: battle-tested identity providers like Okta or Auth0, rate limiting on login endpoints, MFA with number-matching (not just push-approval), and account lockout policies.

#8 — Software & Data Integrity Failures

You're trusting software updates and build pipelines that you've never verified.

This is what happens when your CI/CD pipeline pulls dependencies from unverified sources, your deployment scripts don't validate checksums, and your update mechanism doesn't verify signatures.

Real world: The SolarWinds attack is the canonical example. Attackers injected SUNBURST malware into Orion's legitimate update process. The update was signed with SolarWinds' actual certificate. Organizations installed it because they trusted the vendor. That trust became the weapon.

In June 2024, Polyfill.io — a widely used JavaScript CDN — was acquired by a Chinese company that immediately began injecting malicious code into the scripts served to millions of websites. Every site that loaded polyfill.io scripts without integrity verification became a distribution point for malware without any action from the site owners themselves.

Mitigate with: cryptographic signing of builds and artifacts, verified integrity checks in deployment pipelines, and strict review of third-party CDN dependencies.

#9 — Logging & Monitoring Failures

This is the silent killer.

The breach has already happened. The attacker is already inside. But nobody knows — because nobody is watching.

The Equifax breach in 2017 is the textbook case for this. Apache Struts CVE-2017-5638 was disclosed in March. The patch was available in March. Equifax failed to apply it. Attackers got in on May 13th. Equifax didn't discover the breach until July 29th — over 78 days later. The logging architecture was fragmented. Alerts went to overloaded analysts. No centralized SIEM correlated the suspicious activity. Over 300 security monitoring certificates had expired, including ones monitoring critical domains. 147 million Americans' data was exposed.

The vulnerability let them in. The logging failure let them stay.

Mitigate with: centralized logging, real-time alerting on anomalous patterns, tested incident response plans, and — critically — actually reviewing your alerts.

#10 — Mishandling of Exceptional Conditions

What happens when your application receives input it wasn't designed for?

Most developers design for the happy path. Attackers specifically test what happens when input is chaotic, malformed, oversized, empty, or structurally wrong. If those conditions cause your application to crash, leak data, or behave unpredictably, that predictability becomes exploitable.

Buffer overflows. Integer overflows. Uncaught exceptions that expose stack traces. All of these live in this category.

Mitigate with: fuzzing — automated tools that throw unexpected, malformed, and random inputs at your system to find failure modes before attackers do.

The Pattern Across All 10

Read all of these and one thing becomes clear.

Most of these breaches weren't sophisticated. They weren't the work of nation-state hackers deploying exotic zero-days. They were SQL injection left unchecked. An S3 bucket with the wrong permission. A password hashed with an algorithm from 1995. A log nobody was reading.

The uncomfortable truth is that most breaches happen not because security is hard, but because security is treated as someone else's problem.

It is not.

Security is a design discipline. It belongs in architecture conversations, in code reviews, in your dependency audits, and in your incident response drills. Tools like SAST, DAST, and SCA handle a lot of the mechanical detection. But tools can't fix an architecture that wasn't designed with threat modeling. They can't retroactively salt your password hashes. They can't make your team read the alerts they're ignoring.

The OWASP Top 10 has been published since 2003. The same categories keep showing up. The companies keep changing. The vulnerabilities don't.

That should tell you something.

Which of these is the one your team is most likely to miss? Drop it in the comments.