OWASP Top 10 2025: the ten flaws most likely to break your web app

The OWASP Top 10 is the security industry's most-referenced list of the flaws that most often put web applications at risk, ranked from real-world data rather than opinion. In 2025 OWASP (the Open Worldwide Application Security Project) refreshed the list for the first time since 2021, drawing on more than 175,000 CVE records to re-rank it. The result: Broken Access Control stays at number one, meaning a user reaching data or actions they should never be allowed to. The biggest movers are security misconfiguration jumping from fifth place to second, and software supply chain risk entering the list for the first time as its own high-ranking category at number three. This list is not a magic checklist that makes you secure on its own; it is a map of where to spend your attention first.

The list carries weight because a nonprofit community builds it by looking at real incidents rather than opinions. It is refreshed every three to four years, and plenty of standards and contracts point to it: payment rules like PCI DSS cite OWASP as an example of secure coding, and "do you test against the OWASP Top 10?" has become an almost standard line in vendor security questionnaires. When a software team asks "are we secure?", this is the first place they look. It also gives security people and developers a shared vocabulary to argue over the same thing.

The 2025 edition analyzed 589 distinct weakness types (CWEs) against more than 175,000 CVE records, a clear expansion from roughly 400 types in 2021. The ranking weighs two things together: how often a weakness shows up, and how much damage it does when it is exploited. The trend running through the whole list is a move away from individual coding mistakes toward how software is designed, built, and operated. Security is turning less into "did the developer write this line correctly" and more into "was the software set up correctly in the first place."

Broken Access Control is still number one (A01)

Broken access control is when a user can reach data or actions they should not. The classic example: you change the number in an invoice page's address from 1043 to 1044 and suddenly you are looking at another customer's bill. The cause is simple but widespread, an authorization check that runs on the client side, runs late, or does not run at all on the server. Because most tested applications turn up at least one access-control gap, this item has opened the list for years. In 2025, SSRF (Server-Side Request Forgery), previously its own entry, was folded in here. The right approach is to verify authorization on the server for every request and to default to "deny."

Security misconfiguration climbed to second (A02)

Security misconfiguration is about the environment being set up wrong rather than the code itself: default admin passwords left unchanged, a forgotten cloud storage bucket left open to the internet, debug mode and verbose error messages still on in production, ports and services exposed for no reason. It rose from fifth to second because the move to the cloud made it easy for a single wrong setting to expose an entire dataset to the public. The fix is to work from hardened baseline configurations, switch off every feature you do not need, and add automated checks that flag drift in your settings.

Software supply chain enters near the top (A03)

Software supply chain failures is the expanded version of 2021's "vulnerable and outdated components," and it now covers more than old libraries: the open-source packages you pull in, your build pipeline, and your update mechanism. It landed at number three despite showing up less often in tests, because when a supply chain flaw is exploited the impact is severe. Log4Shell in 2021 and the backdoor planted in the open-source compression tool xz in 2024 are the best-known examples. Protection starts with knowing which dependencies you actually use (a software bill of materials, or SBOM), pinning and scanning them regularly, and treating your build system as seriously as production. We covered this in more depth in a separate post: software supply chain security.

The rest of the list

The remaining seven items matter just as much. A04 Cryptographic Failures (down from second) is weak or missing encryption for data in transit and at rest. A05 Injection (down from third) covers SQL injection and its relatives, where untrusted input from a user turns into a command, and it is still common. A06 Insecure Design is a flaw baked in before a single line of code is written, and its remedy is threat modeling. A07 Authentication Failures (its name simplified) is weak passwords, missing MFA, and broken session handling. A08 Software or Data Integrity Failures is trusting code or updates you never verified. A09 Security Logging and Alerting Failures is not noticing an attack because nothing is recorded or nobody is watching. A10 Mishandling of Exceptional Conditions is entirely new for 2025: systems that fail open instead of closed, and error handling that misbehaves when something unexpected happens.

How to actually use the list

The Top 10 is not a pass-or-fail exam but a frame for building security into your development process. Threat-model against these items during design (A06), scan your dependencies continuously (A03), run automated code analysis (SAST) and tests that probe the running application (DAST), review code with A01 and A05 in mind, and let a penetration test tell you which items are genuinely exploitable in your app. If resources are tight, prioritize the top three, where the most common and highest-impact risks sit. A pentest report and a bug bounty program both tend to speak in OWASP terms, so the list also works as a shared dictionary for tracking risk and talking about it across teams.

At Wedevit we can assess your web application against the OWASP Top 10 2025, wire dependency and configuration scanning into your build pipeline, combine code review with penetration testing and rank the findings by business risk, and leave your team with secure-development habits that stick. The most concrete first step is mapping your application as it is today against these ten items, because until you can see which of them apply to you, you cannot know which one to close first.