What is broken access control?
Broken access control is a security flaw that occurs when an application fails to enforce what authenticated users are allowed to do. When authorization checks are missing or misconfigured, attackers can view other users' data, modify records they should not touch, or escalate their privileges to administrative functions.
OWASP ranks broken access control as A01 in its Top 10, making it the single most prevalent category of web application risk. The reason is straightforward: developers often trust client-side controls or assume that hiding a URL is enough protection. Without explicit server-side enforcement, any user who knows (or guesses) the right request can bypass those assumptions.
Secure Coding Cheat Sheet
Many broken access control bugs start in code. Grab our quick reference for building authorization in from the first commit.
Authentication vs authorization: why the distinction matters
Authentication confirms who you are. Authorization determines what you can do once your identity is established. Broken access control is strictly an authorization problem, which means a user can log in successfully yet still access resources or actions they should never reach.
| Concept | Question answered | Example |
|---|---|---|
| Authentication | Who is this user? | Username and password, MFA, SSO token |
| Authorization | What can this user do? | Role checks, resource ownership, policy evaluation |
A system can have strong authentication in place, including complex passwords and hardware tokens, and still fail on authorization. That happens when the application never checks whether the authenticated user is allowed to perform the requested action. Verifying identity is only the first step; the system must also verify permissions before granting access to resources.
Types of access control failures
Access control failures fall into three main categories. Understanding them helps you design checks that cover every angle.
Vertical privilege escalation: A standard user gains access to administrator-level functions, such as creating accounts, modifying configurations, or viewing audit logs reserved for higher-privileged roles.
Horizontal privilege escalation: A user accesses another user's data at the same permission level. For example, one customer views or edits another customer's order history by changing an ID in the request.
Context-dependent (business-logic) failures: Actions are allowed out of the intended workflow or state. A user might skip a payment step, approve their own request, or reuse an expired discount code because the application trusts the sequence rather than validating it.
What Is Privilege Escalation? Types and Prevention Strategies
Privilege escalation is when an attacker exploits weaknesses in your environment or infrastructure to gain higher access and control within a system or network.
Leggi di più
Common broken access control vulnerabilities and attack techniques
Attackers exploit authorization gaps through several well-documented patterns. Each relies on the same core weakness: the server does not verify that the requester is allowed to access or modify the target resource.
IDOR (insecure direct object reference): The application exposes internal identifiers (account IDs, file names, database keys) without checking ownership. Changing
id=123toid=124returns another user's record.BOLA (broken object-level authorization): The API equivalent of IDOR, common in REST and GraphQL endpoints that accept object identifiers but skip ownership validation.
URL and parameter tampering: Attackers modify query strings, hidden form fields, or request bodies to reference resources or actions they should not reach.
Forced browsing: Directly navigating to paths like
/adminor/reports/allthat are hidden from the UI but not protected on the server.JWT and cookie manipulation: Altering token claims (role, user ID, expiration) when the server fails to verify signatures or accepts weak or 'none' signing algorithms.
Missing function-level authorization: POST, PUT, or DELETE endpoints lack the same permission checks applied to the corresponding GET, allowing users to modify data they can only view.
Real-world examples of broken access control
Consider an e-commerce site where order confirmations live at /orders?id=9001. If the server returns whichever order matches the ID without confirming ownership, any logged-in user can iterate through IDs and download invoices, shipping addresses, and payment details for thousands of customers.
Another common scenario: an admin panel sits at /admin. The navigation menu hides the link for non-admin users, but the route itself has no role check. Anyone who types the URL gains full administrative access.
In API-driven applications, the risk multiplies. A mobile app might call PUT /api/users/456 to update profile details. If the backend trusts the ID in the path without verifying that the authenticated token belongs to user 456, attackers can overwrite any account. In practice, this means a single missing check turns a personal profile feature into a mass-account-takeover vector.
Broken access control in the cloud
Authorization failures do not stop at application code. When workloads move to the cloud, the same gaps reappear as over-permissive IAM policies, public storage buckets, and service accounts that violate least-privilege principles.
A developer might attach a broad policy to a Lambda function during testing and forget to scope it down before production. That function can now read secrets, write to databases, or invoke other services far beyond its intended purpose. Wiz's 2025 Cloud Data Security Snapshot found that 72% of cloud environments have publicly exposed PaaS databases lacking sufficient access controls. When default permissions and forgotten policies stack up across hundreds of services, broken access control stops being a single misconfiguration and becomes a systemic risk.
Infrastructure-as-code templates ship these misconfigurations to every environment they provision. If a Terraform module defines an overly permissive role, every deployment inherits the risk. Detecting broken access control therefore requires visibility not only into running resources but also into the code and pipelines that create them.
How to prevent broken access control
Prevention starts with a mindset shift: treat every request as untrusted until the server explicitly authorizes it. The following practices translate that mindset into actionable controls.
Deny by default: Reject access unless a rule explicitly grants it. Allowlists are safer than blocklists.
Enforce authorization server-side: Never rely on client-side checks, hidden fields, or URL obscurity. Validate permissions on every request.
Apply least privilege and RBAC: Grant users and service accounts only the permissions they need. Review roles periodically and revoke stale access.
Use non-guessable references: Replace sequential IDs with UUIDs or indirect references. Combine with ownership checks so guessing still fails.
Invalidate sessions and tokens promptly: Expire JWTs, rotate API keys, and revoke sessions on logout or privilege changes.
Log and rate-limit sensitive actions: Record authorization decisions, flag anomalies, and throttle enumeration attempts.
Test authorization explicitly: Include automated tests that verify users cannot access resources outside their scope. Run these tests in CI/CD so regressions fail the build.
Watch 5-min demo
See how these prevention practices come together in a live environment.
How to detect broken access control across code and cloud
Manual testing with tools remain valuable for probing complex authorization logic, but they do not scale across hundreds of microservices and thousands of cloud resources. Effective detection combines static analysis, infrastructure scanning, and runtime validation.
Shift authorization checks left by scanning code and IaC templates for IDOR patterns, missing ownership validations, and overly permissive policies before deployment. Then confirm exposure by correlating those findings with the running cloud environment, so you know whether a vulnerable code path is actually reachable and connected to sensitive data. Continuous monitoring matters too, because new deployments and permission changes can reintroduce gaps that a one-time scan would miss.
This code-to-cloud approach accelerates remediation. When security teams can trace a runtime finding back to the exact line of code and the developer who owns it, fixes happen faster. Zendesk embedded security checks early in the development lifecycle and eliminated 96% of its critical vulnerabilities, demonstrating what becomes possible when detection spans the full software delivery pipeline.
How Wiz helps prevent broken access control
Wiz connects code, cloud infrastructure, and runtime behavior in a single security graph. This unified view lets teams trace a permission flaw in application logic all the way to the exposed cloud resource it affects, turning fragmented signals into a clear picture of real risk.
Finding those flaws starts early in the development process. Wiz AI-SAST (static application security testing) moves past legacy pattern-matching scanners by performing deep, multi-file semantic reasoning that models how an attacker would actually move through the application. That approach uncovers business-logic vulnerabilities like broken access control and IDOR (insecure direct object reference) that traditional tools routinely miss.
Once code reaches the cloud, agentless CIEM (cloud infrastructure entitlement management) maps complex IAM (identity and access management) policies into clear visual pathways. Excessive Access Findings surface over-privileged identities, helping teams enforce least privilege without manually combing through tangled policy files. Because the security graph ties these code-level flaws directly to cloud entitlements, teams can see which identities could actually exploit which vulnerabilities.
Security and development teams work from the same view of risk, so gaps close faster and stay closed. Get a demo to see how Wiz helps you close authorization gaps from code to cloud.
See broken access control risk in context
Walk through how Wiz traces an authorization gap from code to the exposed cloud resource and prioritizes it by real exploitability.
