OWASP just updated this list for the first time since 2021. Two categories are brand new, and the ranking shifted more than most people realize. Here is what it all actually means.
If you have ever sat in a meeting where someone mentioned the OWASP Top 10 and nodded along without really knowing what it meant, you are in good company. It sounds like something only developers need to care about. It is not. It is closer to a list of the ten most common ways a business website or app actually gets broken into, updated by security researchers who study real breaches for a living.
OWASP just released the first major update to this list since 2021, built on an analysis of more than 175,000 real vulnerability records. Two categories are brand new. Several others moved up or down the ranking in ways that say a lot about how attacks have actually changed in the last few years.
This post walks through all ten, in plain English, what each one actually means, why it matters, and what it would look like if it happened to your business.
What the OWASP Top 10 Actually Is, and Isn’t
OWASP is a nonprofit that has spent over two decades studying how web applications get attacked. The Top 10 is not a law or a certification. It is closer to a most wanted list, the ten categories of weakness that show up most often in real breaches, ranked by how frequently they are found and how much damage they tend to cause. Developers use it to know what to build defenses against. Security teams use it to know what to test for. Business owners mostly just need to know it exists, and that their applications are being measured against it whether they realize it or not.
Broken Access Control Is Still Number One, and Now It’s Bigger
This one is simple at its core: the app fails to properly check whether the person asking for something is actually allowed to have it. A regular user finds a way to see another customer’s invoice, or reach an admin only page just by knowing the right web address. It has held the top spot since the last update, and this year it grew to explicitly cover a couple of specific patterns that are increasingly common wherever apps talk to each other through APIs, one where a user manipulates a reference number to view someone else’s data, and another where a lower level user finds they can call an administrator only function directly, simply because nothing was checking who was asking.
Security Misconfiguration Jumped From Fifth to Second
This is the category of pure, avoidable mistakes, default passwords never changed, cloud storage left open to the public, error messages that accidentally reveal internal system details to anyone who triggers them. Every single application OWASP tested for this update had some form of misconfiguration present. The jump to second place is not really about developers getting careless. It reflects how fast software gets deployed now, teams push updates constantly, but security reviews often happen far less often, leaving a gap where something is live and exposed before anyone checks it.
Software Supply Chain Failures Is Brand New, and Already the Most Common
This is one of two categories that did not exist on the last list at all, and it debuted with the highest rate of real world occurrence of any category. It covers the risk hiding in everything your application depends on but did not build itself, third party code libraries, the tools used to build and deploy your software, and the update mechanisms that push new versions live. A famous real world example is the SolarWinds breach, where attackers compromised a legitimate software update, and it reached thousands of organizations who had no reason to suspect the update itself was the problem.
Cryptographic Failures Dropped, But Don’t Read That as Good News
This covers weak, missing, or outdated encryption, sensitive information sitting unprotected, or protected with methods that are no longer considered safe. It fell from second to fourth place, which mostly reflects that basic encryption has become more standard across the industry, not that the consequences got any smaller. For any business handling payment details, medical records, or other regulated data, a failure here still leads directly to the kind of breach that triggers compliance penalties, not just embarrassment.
Injection Is Still Dangerous, Just Hiding Somewhere New
This is the classic vulnerability most people picture when they think of hacking, tricking an application into running a command it was never supposed to execute, often by typing something unexpected into a form field. It dropped a couple of spots, largely because tools have gotten better at catching it on the visible parts of a website. The catch is that most of these checks focus on forms a human fills out, while a growing share of how data enters an application now happens through APIs, machinery talking to machinery, that often never gets tested the same way.
Insecure Design Is the Flaw No Scanner Can Catch
Every other category on this list describes something that can, in theory, be found by testing a finished application. Insecure design is different. It describes a security gap that was built into the blueprint before a single line of code was written, a missing requirement, a feature designed without asking what could go wrong with it. No automated tool can retroactively redesign an application. This is why involving security thinking early, before development starts, tends to be dramatically cheaper than fixing the same flaw after launch.
Authentication Failures: Where the Login Page Isn’t the Real Target
This covers weaknesses in how an application verifies who someone actually is, weak password rules, no protection against automated login guessing, sessions that do not properly expire. The part worth knowing is that the actual weak point is increasingly not the login page itself, but the behind the scenes connections between systems and services that also require authentication and often get far less attention.
Software and Data Integrity Failures: Trusting an Update You Never Verified
This is closely related to the supply chain category above, but distinct. Supply chain failures are about what you depend on. This category is about whether your own application and the way it receives updates actually verify that what is arriving is genuine and untampered with, rather than assuming it is safe simply because it looks like it came from the right place.
Why this matters
Two categories, two different questions. Can you trust the ingredients you’re building with, and can you trust the delivery truck bringing your next update. A business needs an answer to both.
Security Logging and Alerting Failures: A Word Change That Says a Lot
This category used to be called Monitoring. It is now called Alerting, and that single word swap is the whole point. A system that quietly records everything that happens, but never tells anyone when something suspicious occurs, is not actually protecting anything. It is just keeping notes for after the damage is already done. Logs that nobody reviews are not a security control, they are evidence for a report nobody wanted to have to write.
Mishandling of Exceptional Conditions: The Newest Category, Straight From the Field
The second brand new category on the list, and the one added directly because security professionals kept encountering it in real incidents before it had an official name. It covers what happens when something goes wrong in unexpected ways, an error message accidentally revealing internal system details, or a system defaulting to letting everyone in when a security check fails to run properly instead of defaulting to locking everyone out. The core principle it points to is simple: when something breaks, a system should fail closed, not fail open.
Why Two New Categories Appeared at Once
New categories on this list are rare, the entire top ten only gets revised roughly every three to four years. Two appearing in the same update reflects genuine change in how software gets built and attacked, more dependence on third party code and automated deployment pipelines, and enough real incidents involving poor error handling that practitioners pushed for it to get its own category rather than staying buried inside broader ones.
Not sure where your own applications stand against this list?
Book a free security assessment and Ambsan’s team will show you exactly which categories apply to your specific setup.
What This List Actually Means for a Pakistani Business, Not Just Developers
If your business has any website, customer portal, or app that handles logins, payments, or personal information, this list describes real risk to your business, not an abstract developer concern. A broken access control flaw does not care whether your company has a security team. A misconfigured cloud storage bucket does not check your company size before exposing customer records. The businesses that treat this list as background reading tend to be the ones explaining a breach to a client afterward, not preventing one beforehand.
Checklist: Where to Start If You’ve Never Looked at This List Before
- Confirm someone can tell you, in plain terms, whether your applications have ever been tested against these ten categories
- Ask specifically whether your APIs are tested, not just your website’s visible forms and login pages
- Check whether default settings and credentials were ever changed on your production systems, not just assumed to be fine
- Find out whether your team maintains a list of every third party library and dependency your applications rely on
- Confirm that security logs are actually reviewed and trigger alerts, not just stored somewhere unread
- Ask what happens in your systems when something fails, do they lock down safely, or quietly let things through
How Ambsan’s Application Security and VAPT Work Maps to This List
Ambsan’s Application Security solutions and VAPT service are built around exactly this kind of testing, checking real applications against real, current attack categories, not a generic checklist from years ago. That includes API specific testing for the access control and injection risks that traditional scanning tends to miss, dependency and supply chain review for the newest and highest incidence category on this list, and practical guidance on fixing what gets found, not just a report listing it.
This work connects directly to Ambsan’s broader security stack, since an application vulnerability caught early is a problem solved for a fraction of the cost of the same flaw discovered after a breach.
See where your applications actually stand
Ambsan’s team tests your applications against the current OWASP Top 10, not an outdated checklist, and shows you exactly what needs attention.
Book a Free Security Assessment
Explore VAPT Services
Frequently Asked Questions
What is the OWASP Top 10?
The OWASP Top 10 is a widely referenced list of the ten most critical security risks to web applications, published by the nonprofit OWASP Foundation based on real world vulnerability data and input from security professionals worldwide.
How often does the OWASP Top 10 get updated?
Roughly every three to four years. The most recent update is the first major revision since 2021, based on analysis of over 175,000 CVE records collected in the years between.
What are the two new categories in the latest OWASP Top 10?
Software Supply Chain Failures and Mishandling of Exceptional Conditions are both new. The former addresses risk from third party dependencies and build pipelines, and the latter covers systems that fail unsafely when something unexpected happens.
Why did Security Misconfiguration jump so far up the list?
It moved from fifth to second largely because modern deployment happens far more frequently than security reviews do, creating gaps where a misconfigured system is live and exposed before anyone checks it.
Is the OWASP Top 10 only relevant to developers?
No. While developers use it to guide secure coding practices, it directly describes risk to any business operating a website, customer portal, or application, regardless of whether that business has an internal technical team.
What is Broken Access Control, in simple terms?
It is when an application fails to properly verify whether the person requesting something is actually allowed to have it, allowing users to view or modify data or functions that should be restricted to someone else.
Does my business need to test against all ten categories?
Most applications are exposed to several of these categories at once, since many overlap in practice. A proper security assessment or penetration test typically evaluates an application against the full list rather than picking categories selectively.
What is the difference between Software Supply Chain Failures and Software and Data Integrity Failures?
Supply chain failures concern the third party components and tools your application depends on. Integrity failures concern whether your own application and update mechanism verify that what they receive is genuine and unaltered. Both need attention, since they are often exploited together.
How can a business start addressing OWASP Top 10 risks?
The most practical starting point is a professional security assessment or penetration test that evaluates existing applications against the current list, identifying which categories represent real, present risk rather than trying to address all ten in the abstract.
Final Thoughts
The OWASP Top 10 is not designed to be intimidating, it is designed to be useful, a shared, evidence based answer to the question of where applications actually break in the real world. This update reflects genuine shifts in how software gets built, more third party dependencies, faster deployment cycles, more machine to machine communication through APIs, and the risks that come with all of it.
Reading this list is the easy part. Knowing where your own applications actually stand against it is the part that requires an honest look, not an assumption.
Related: Black Box vs White Box vs Grey Box Penetration Testing, Which One Does Your Business Actually Need
Related: SIEM vs SOC, The Difference That Decides Whether Your Alerts Ever Get Seen
Related: Endpoint Security Compliance, What Businesses Need for ISO 27001, PCI DSS, and Cyber Insurance
Ready to see how your applications measure up?
Book a free, no obligation consultation with Ambsan’s team and get a clear picture of your real application security posture.
Schedule a Consultation
See All Services
Ambsan Technologies is a Karachi based cybersecurity firm serving businesses across Pakistan and the United States, offering application security, VAPT, and managed IT services for SMEs and enterprises.