OWASP Top 10 2021 shows access control still drives web risk

At a glance

What this is: INTIGRITI’s analysis of OWASP Top 10 2021 shows broken access control back at number one, with SSRF newly recognised as a high-priority web risk.

Why it matters: For application security, IAM, and product teams, the ranking underlines that authorization boundaries, session controls, and design-time guardrails are still the controls most likely to fail first.

By the numbers:

• Open redirects account for 5% of all submissions on Intigriti’s platform.
• Improper access control accounts for 4% of all submissions on Intigriti’s platform.
• Improper authentication accounts for 4% of all submissions on Intigriti’s platform.
• Server-side request forgery accounts for 2% of all submissions Intigriti receives.

Context

OWASP Top 10 is a risk ranking, not a vulnerability checklist. Its value is in showing where application controls fail repeatedly enough to shape practitioner priorities, especially around authorization, authentication, configuration, and design.

The 2021 edition matters because it reflects a broader shift in web risk: frameworks now absorb some classic coding errors, while access control mistakes, SSRF, and integrity failures expose where modern applications still break down. For IAM and application security teams, the boundary between identity, session, and authorization remains central.

The article’s starting position is typical of current web security practice: organizations are less exposed to hand-rolled authentication flaws than they were a decade ago, but they still struggle to govern what users and services are allowed to do once authenticated.

Key questions

Q: What breaks when broken access control is not enforced server-side?

A: When access control is only checked in the UI or at login, attackers can call protected APIs, change object identifiers, or invoke functions they should never reach. The result is often horizontal or vertical privilege abuse, where authenticated users act outside their intended scope. Server-side authorization must enforce both who the user is and what that user may do.

Q: Why does SSRF create such a large security impact even when it is relatively uncommon?

A: SSRF is dangerous because it lets an attacker use the server as a proxy into internal systems. That can bypass network controls, reach metadata services, and expose management interfaces that were never meant to be internet-facing. Low frequency does not reduce impact when the application becomes a bridge into trusted infrastructure.

Q: What do security teams get wrong about authentication controls and trust?

A: They often assume that operating a control is the same as controlling trust. In practice, phishing, relay attacks, and delegated access can bypass or reshape the control path entirely. The mistake is treating credential policy as the whole security model rather than one input to a broader trust decision.

Q: How should organisations balance vulnerability scanning with secure-by-design reviews?

A: Scanning remains useful, but it cannot find every trust failure embedded in architecture, dependency handling, or release pipelines. Secure-by-design review is needed to catch flaws such as missing authorization boundaries, unsafe request handling, and unverified integrity controls before they become repeatable production risk.

Technical breakdown

Why broken access control keeps returning to the top

Broken access control occurs when a user or system can act outside its intended permissions. In practice, this is rarely a single bug. It is usually a control failure across object-level authorization, function-level authorization, token handling, and request validation. The article highlights cases such as unauthorized API access, privilege escalation, JWT tampering, and viewing another user’s records. That mix is important because it shows access control as a system property, not just a single code check. When authorization is weak, identity becomes proof of login rather than proof of scope.

Practical implication: treat authorization as an end-to-end control spanning sessions, APIs, and object checks, not as a one-time login control.

How SSRF turns user input into internal network reach

Server-side request forgery happens when an application accepts a user-controlled URL or destination and then makes a backend request on the attacker’s behalf. That can let an external user reach internal services, scan ports, or bypass firewall and ACL assumptions that only protect the perimeter. SSRF matters because the server’s trust boundary becomes the attacker’s transport path. The article also notes that SSRF was included for its impact potential rather than sheer frequency, which is a reminder that low-volume issues can still have high blast radius when they reach internal metadata services, admin interfaces, or service endpoints.

Practical implication: validate and constrain outbound requests, especially where applications can reach internal services or cloud metadata endpoints.

Why design and integrity issues now sit beside classic injection

The 2021 Top 10 moves beyond input injection to highlight insecure design and software and data integrity failures. That shift reflects a control reality: some of the most damaging flaws are not bad syntax but missing guardrails in architecture, build pipelines, and trust decisions. The article’s SolarWinds reference is relevant because it shows how unverified integrity can turn a normal update path into a compromise path. For web teams, the lesson is that secure design includes dependency trust, build assurance, and the assumptions behind how data and code are accepted into production.

Practical implication: build integrity checks and secure-by-design review into release pipelines, not just into application code reviews.

Threat narrative

Attacker objective: The objective is to cross authorization boundaries and reach data, functions, or internal resources that should not be available to the attacker.

1. Entry begins when an attacker uses a broken access control path, an SSRF vector, or weak authentication to interact with functionality outside the intended trust boundary.
2. Credential or token abuse follows when the application accepts tampered JWTs, weak sessions, or insufficient authorization checks that let the attacker move beyond a normal user scope.
3. Impact occurs when the attacker reaches another user’s records, internal services, or administrative functions that the application was supposed to protect.

Breaches seen in the wild

• Tesla Kubernetes cryptojacking 2018: Attackers used Tesla's unprotected Kubernetes console to find AWS credentials in a pod and mine cryptocurrency, RedLock reported in February 2018.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Broken access control is now a governance problem, not just a code defect. The article’s examples show that authorization failures span APIs, tokens, object references, and session logic. That means identity proof is not the same as permission proof, which is where many application programmes still over-assume safety. Security teams should treat authorization scope as a first-class control objective.

SSRF is a boundary-crossing problem disguised as a web input issue. The real risk is not the parameter alone, but the application’s ability to turn untrusted input into trusted backend reach. Once that path exists, perimeter assumptions, internal service isolation, and cloud metadata protections all matter at once. Practitioners should regard SSRF as an access-path control issue, not a simple filtering bug.

Secure design has become the missing control layer between development speed and trust. OWASP’s reclassification of design and integrity failures shows that classic vulnerability scanning does not cover architectural trust mistakes. Where software supply paths, dependency trust, or build integrity are weak, the application may be functioning exactly as coded while still being insecure by design. The implication is that secure-by-design review now belongs alongside testing, not after it.

Identity-aware authorization is the category’s most durable control theme. Broken access control and broken authentication are different, but they fail together when identity is accepted without scope enforcement. That makes identity governance relevant to web risk even outside IAM programmes. The practitioner conclusion is simple: if users or services can authenticate without tightly bounded rights, the application has not actually established trust.

What this signals

Identity-aware authorization is the control theme that keeps repeating across modern web risk. As frameworks absorb more basic coding mistakes, the failures that remain are the ones tied to scope, trust, and who is allowed to do what after authentication. For practitioners, that means access decisions must be enforced at the server, not inferred from the user interface.

SSRF shows why perimeter thinking no longer protects internal trust zones. Once an application can make backend requests on behalf of an attacker, network boundaries become control assumptions rather than control guarantees. Teams should watch for internal service exposure through application paths, not just through direct internet-facing endpoints.

For practitioners

• Tighten object and function authorization checks Review endpoints for missing server-side authorization on every object and action, especially POST, PUT, delete, and admin functions. Do not rely on the UI to enforce permissions.
• Constrain SSRF-prone outbound requests Restrict which hosts, schemes, and destinations applications can call, and isolate access to internal services and metadata endpoints from user-controlled requests.
• Rework authentication into session and scope control Verify that logged-in users can only access their own records and approved functions, and that token claims are enforced by the server rather than trusted from the client.
• Add integrity checks to build and release paths Require signing, provenance, and verification for code and dependencies so that a trusted deployment path cannot quietly become a compromise path.

Key takeaways

• Broken access control remains the most persistent web application risk because it combines authorization gaps, session weakness, and token abuse in one failure mode.
• SSRF matters less for how often it appears than for how far it can reach once an application turns user input into trusted backend traffic.
• The ranking shift signals that secure design, build integrity, and identity-aware authorization now need to sit alongside traditional injection testing.

Key terms

• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.
• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Cryptographic Failure: A weakness in how data is protected in transit or at rest, usually caused by bad key management, exposed secrets, or inconsistent enforcement rather than weak algorithms alone. It matters because strong encryption can still fail when the credentials behind it are poorly governed.
• Software Or Data Integrity Failure: A software or data integrity failure happens when a system trusts an artifact, update, or payload without verifying that it is authentic and unchanged. The risk is especially high in CI/CD, package delivery, and runtime updates where unsigned or tampered inputs can be executed as trusted code.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and machine identity security. It helps practitioners connect access control, privilege scope, and governance decisions across modern identity programmes.