Broken Access Control
OWASP Top 10 (Web Application Security Risks) · A01:2025
Access control decides who may do what. It breaks when an application checks identity but never properly re-checks authority on the server for the specific action and record being requested. Because the rules live in application logic rather than in a single enforceable boundary, gaps are easy to introduce and hard to spot in review. In the 2025 edition this category also absorbed server-side request forgery, on the reasoning that tricking a server into making a request on your behalf is itself a failure to constrain what the server is permitted to reach.
The 2025 edition replaced the long-running 2021 edition. Many certification exams still test the 2021 list, so both are shown on this page.
How it shows up in the real world
- Changing an invoice or user id in a URL or API path and receiving another customer's record, because the server loads the object by id without checking who owns it.
- An ordinary user reaching an administrative endpoint directly, because the only thing hiding it was that the link is not rendered in their menu.
- Editing a hidden form field, JSON property, or JWT claim such as a role or tenant id and having the server trust it.
- Submitting an internal address to a feature that fetches a user-supplied URL, so the server reaches cloud metadata services or internal-only hosts on the attacker's behalf.
How to mitigate it
- Deny by default: every route and every record access requires an explicit positive authorization decision.
- Enforce authorization server-side in one shared, testable layer rather than scattering ad-hoc checks through controllers and templates.
- Make ownership part of the query itself, so a record is fetched scoped to the caller's tenant or user rather than fetched and then checked.
- Treat all client-supplied identifiers, roles, and tenant hints as untrusted input; derive authority from the server-side session instead.
- Restrict outbound requests from server-side fetchers with allow-lists, and block link-local and private address ranges.
- Write automated tests that assert a low-privilege user is refused, not merely that a high-privilege user succeeds.
Practice this topic
Test your knowledge of Broken Access Control with exam-style practice questions.
Rest of the Web 2025 list
A02:2025Security Misconfiguration
Software is usually far more permissive out of the box than it needs to be in production, and modern systems have an enormous amount of configuration surface: frameworks, containers, orchestrators, cloud services, identity providers, and CI systems all carry their own defaults. This category covers the security you never switched on, the sample content you never removed, and the environment differences nobody reconciled. It climbed to second place in the 2025 edition, reflecting how much of a deployment's risk now sits in configuration rather than in code.
A03:2025Software Supply Chain Failures
New in the 2025 edition, and a broadening of what used to be framed narrowly as vulnerable and outdated components. The point is that you inherit risk from everything involved in producing and delivering your software, not just from the libraries you import: package registries, build systems, CI/CD runners, base images, plugins, and the third-party services your build trusts. An attacker who compromises any of those can have malicious code signed and shipped through your own legitimate release process.
A04:2025Cryptographic Failures
This category is about failures to protect data that deserves protection, whether in transit, at rest, or in backups and logs. The failures are rarely broken mathematics; they are missing encryption, obsolete algorithms, reused or hard-coded keys, weak randomness, and passwords stored with fast hashes. The first question is always a data-classification question: what are you holding, does it need protection, and for how long.
A05:2025Injection
Injection happens when untrusted input is concatenated into something an interpreter parses, so data crosses the boundary and is treated as instructions. The interpreter varies — SQL, the shell, an LDAP or XPath query, a template engine, a NoSQL document, or the browser's HTML parser in the case of cross-site scripting — but the shape of the bug and the fix are consistent: keep code and data structurally separate rather than trying to guess which characters are dangerous.
A06:2025Insecure Design
Some weaknesses cannot be patched because nothing is technically broken — the system was specified to behave that way. Insecure design covers missing or inadequate security controls in the design itself: a workflow that can be replayed, a trust assumption that does not hold, a recovery mechanism weaker than the thing it protects. A perfect implementation of a flawed design is still insecure, which is why this category is addressed with threat modelling and reference architectures rather than with scanners.
A07:2025Authentication Failures
Authentication establishes who is making a request, and session management preserves that answer across subsequent requests. This category covers weaknesses in both: credential stuffing and brute force that go unthrottled, factors that can be phished or relayed, and sessions whose tokens are predictable, long-lived, or never invalidated. Because credentials are the most consistently attacked part of any application, small gaps here tend to be found and exploited quickly.
A08:2025Software or Data Integrity Failures
Integrity failures occur when a system accepts code, updates, or structured data without verifying that it is what it claims to be and has not been altered. Deserializing attacker-controlled objects is the classic technical case, because many deserializers can be steered into constructing dangerous types and reaching code execution. The broader case is any trusted-by-default input: an unsigned update, a script pulled from a third party, or a CI step that consumes an unverified artifact.
A09:2025Security Logging and Alerting Failures
This category is about not being able to tell that something happened. If security-relevant events are not recorded, or are recorded somewhere nobody watches, an intrusion continues until an outsider notices. The 2025 edition renamed the category to emphasise alerting rather than passive monitoring: the failure is usually not an absence of data but an absence of anything that turns data into a timely response. Logging failures also make incident response and forensics much harder after the fact.
A10:2025Mishandling of Exceptional Conditions
New in the 2025 edition. This category covers what a system does when something goes wrong: an unhandled error, an unexpected input, a dependency timing out, a resource running short. Failure is inevitable, so security depends on failing in a defined and safe direction. The common pattern is a control that silently degrades — an authorization or verification step that returns an error which is treated as success, or an exception path that skips cleanup and leaves the system in an inconsistent state.