Earlier this month, hackers took over Instagram accounts without cracking a single password. All they did was ask Meta’s AI support chatbot to add a new email address to each account, and it complied. The chatbot was authorized to perform account recovery actions, but it never verified whether the person on the other end of the conversation was authorized to request them.
That’s a form of broken access control, which has held the top spot in the OWASP Top 10 since 2021, and incidents like this show why it stays there. The problem is that authorization logic is hard to test, static analysis doesn’t reliably catch it, and AI coding assistants are now generating it at scale.
What is Broken Access Control?
Broken access control occurs when a system performs a privileged action without verifying whether the requester is authorized, whether as a logged-in user accessing data they shouldn’t, or an automated system acting on instructions without checking who’s behind them.
Authentication verifies your identity, but authorization decides which data and actions a user can access after logging in. When authorization is missing or easy to bypass, an attacker who’s logged in as a regular user can view other people’s records and modify data that isn’t theirs, or even access admin functions they weren’t supposed to see.
The OWASP Foundation describes broken access control as failures that “typically lead to unauthorized information disclosure, modification, or destruction of data.” Since applications define their own access rules based on business needs, authorization flaws are hard to detect automatically and can persist across security programs.
Why Broken Access Control Tops the OWASP Top 10
Broken Access Control remains at the top because authorization logic is hard to implement consistently, especially when it’s spread across multiple services and endpoints. Despite organizations investing in scanners and other tools, the same authorization issues keep appearing in production.
Whereas input validation or encryption can be handled generically, authorization rules are application-specific. A healthcare app, an e-commerce platform, and a banking system all have completely different definitions of who can access what. No generic library or framework can automatically solve authorization.
When it comes to managing permissions, many applications use formal models such as Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC). As the name suggests, RBAC assigns access based on roles like “admin” or “user”. ABAC uses characteristics or attributes such as user identity, resource type, or request context to decide what’s allowed.
However, these models are often inconsistently applied across services, leading to differences in how access control rules are enforced in the codebase.
Static analyzers can detect issues such as missing input validation, but they cannot determine whether a given user should access a particular record. That decision depends on the business context that only developers understand.
Broken Access Control Patterns in Production Code
It doesn’t matter what the technology stack is; there are certain authorization vulnerabilities that keep showing up. It’s why recognizing patterns can help teams catch them before attackers do.
Insecure Direct Object References (IDOR)
The name might sound a bit complicated, but basically, IDOR occurs when an application exposes internal identifiers, such as database IDs or filenames, without verifying whether the user is allowed to access them.
For example, if you’re ordering something there might be a URL such as /api/orders/12345 that displays the order details. If the application doesn’t verify that you own that order, it’s possible to change the number to 12346 and expose someone else’s order information. The system assumes the ID in the URL is legitimate without checking whether you have permission to view it.
Broken Object-Level Authorization (BOLA) in APIs
BOLA is essentially IDOR happening in APIs. When an API endpoint accepts an object ID, such as a user profile or order number, it may fail to check that you have permission to access that specific object.
The OWASP API Security Top 10 lists BOLA as the number one API risk. APIs are particularly vulnerable because they’re designed for automated access between systems, making it easy for attackers to enumerate IDs and look for API authorization flaws.
Missing Function-Level Access Control
Sometimes the issue isn’t accessing data, but performing actions the user shouldn’t be allowed to take. An ordinary user might access /admin/deleteUser by guessing the URL, because the system never checks whether they have admin rights.
These flaws let attackers access resources belonging to other users at their level (such as viewing another customer’s orders), or perform admin functions they shouldn’t have (such as deleting user accounts). The application might hide admin buttons from regular users, but if the server doesn’t verify permissions when someone requests that page, anyone who knows the URL can access it.
Forced Browsing and URL Tampering
Another method attackers use is to look for unprotected pages by modifying URLs or guessing paths. Client-side restrictions, for instance, hiding buttons or links, provide no proper protection if the server responds to direct requests.
Privilege Escalation Through Role Confusion
Some applications let users accidentally change their own permission levels. For example, there could be a form that includes a hidden field with the value role=admin. If the server accepts whatever value the user sends without double-checking, someone could grant themselves administrator access by modifying that field.
CORS and Cross-Origin Authorization Failures
Cross-Origin Resource Sharing (CORS) controls which websites are allowed to make browser-based requests to your API. When these settings are configured too loosely, attackers can build malicious websites that make requests to your API on behalf of logged-in users.
The Impact and Business Cost of Broken Access Control
It’s not surprising that the impact of authorization failures can be huge, with organizations facing immediate disruption and long-term reputational damage. IBM’s 2025 report places the average cost of a data breach at $4.44 million.
-
Data exposure: Attackers can access customer records, financial data, or healthcare information, leading to breach notifications and regulatory investigations.
-
Compliance breaches: Frameworks such as GDPR, HIPAA, and PCI DSS give penalties when sensitive data isn’t properly protected.
-
Operational disruption: Incident response moves developers away from feature work, and fixing the issue often requires changes to system architecture.
-
Loss of trust: Public disclosure erodes trust with customers and partners, and that’s harder to recover from than the technical fix.
The cost of fixing authorization flaws also increases the later they’re discovered. A design-stage fix might take hours, but a production incident can last for weeks.
Why Security Initiatives Fail to Eliminate Broken Access Control
Despite investment in application security, broken access control remains a problem. Understanding why helps teams choose more effective ways to counter it.
SAST and DAST Tools Lack Authorization Context
Static and dynamic analysis tools excel at finding syntax errors, injection flaws, and configuration issues. However, they cannot understand business logic.
A scanner has no way to know that User A shouldn’t access Order #12345, as that knowledge lives in requirements documents and developers’ heads. Tools can find potential issues, but they cannot determine whether business rules permit a given access pattern.
Pen Tests Find the Same Flaws Every Cycle
Penetration testing can identify authorization issues, but only the ones present when the assessment takes place. As new features are added, the same weaknesses can be introduced again before the next test.
There needs to be continuous prevention; if not, teams end up repeatedly fixing the same vulnerability types. BreachLock’s 2025 report, for example, found broken access control in 32% of high-severity pentest findings. It’s the underlying development practices that have to change.
Generic Training Does Not Build Authorization Intuition
Passive security awareness courses explain what broken access control is, but they don’t always help developers properly understand what the vulnerability is all about. Reading about IDOR is different from exploiting one in a lab environment.
Hands-on practice in exploiting and fixing authorization flaws in realistic environments builds the intuition that prevents mistakes in production code.
Code Review Misses Implicit Trust Assumptions
Reviewers focus on the code that’s in front of them, but authorization issues are often invisible. The absence of a check is harder to find than incorrect logic, making secure code review especially challenging for authorization flaws.
If there are no explicit checklists or automated policy enforcement, missing authorization checks go unnoticed during review. Reviewers see what’s there, not what’s missing.
Microservices and APIs Multiply the Authorization Surface
Distributed architectures need consistent authorization between services. A monolith application (a single, connected system) might have one authorization layer, whereas a microservices system might have dozens.
Every service boundary that’s added leads to more risk. One service might verify access properly, while another assumes it was already handled upstream, and attackers often target these gaps.
How AI-Generated Code Amplifies Broken Access Control
It’s well known that AI coding assistants speed up development, but they also introduce authorization issues at the same fast rate. Models trained on public repositories generate functionally correct code that compiles and runs, but AI-generated code makes up to 2.74× more vulnerabilities than human-written code, often lacking the authorization checks specific to your application.
Let’s say a developer prompts an AI to “create an endpoint that returns user profile data.” The generated code will probably fetch the record by ID, but doesn’t verify ownership. The result works perfectly in testing, where the developer uses their own account. In production, however, it becomes an IDOR vulnerability.
Why AI Coding Assistants Miss Authorization Context
AI assistants don’t usually have the full surrounding context of an application. AI models don’t have access to your application’s access control policy, user roles, data ownership rules, or business requirements. They generate patterns based on training data, not your security specifications.
-
Insecure training examples: AI models learn from public repositories, many of which contain weak or incomplete authorization logic that models can reproduce in generated code.
-
Missing policy context: AI doesn’t know who should have access to what in your environment. Without that context, it can’t apply your organization’s authorization rules.
-
Prompt limitations: Developers usually ask AI to build a feature or endpoint, not to implement every authorization requirement that should go with it. If those requirements aren’t specified, they’re often left out.
-
False sense of correctness: The generated code may look complete and work as expected during testing, but critical authorization checks can still be missing.
A Multi-Layered Strategy to Prevent Broken Access Control in the SDLC
To prevent these vulnerabilities, authorization needs to be addressed at every stage of the software development lifecycle, not just during code review or testing.
1. Model Authorization Threats Before Code Is Written
Threat modeling during design identifies authorization requirements early, when changes are inexpensive. Teams can map data flows, identify trust boundaries, and define who can access what.
Automated threat modeling tools can generate security controls mapped to specific threats, making the process faster and more consistent than manual diagramming.
2. Define Secure Defaults and Deny-by-Default Policies
If frameworks and APIs are set up to deny access by default, it reduces the impact of missing checks. All that happens with a missing authorization check is that it blocks access instead of exposing data.
3. Centralize Authorization Logic and Avoid Implicit Trust
It’s much easier to review and maintain authorization in a central location, instead of having checks throughout the codebase. Passing requests through the same rules before they reach business logic leads to fewer mistakes.
4. Review AI-Generated Code Against Authorization Requirements
It should go without saying these days, but all AI-generated code needs to be reviewed carefully against authorization requirements. For example, teams should make sure ownership is verified before data is returned and that role-based access controls are used for sensitive actions. They should also ensure user-supplied IDs can’t be used to bypass authorization.
5. Test Access Control Continuously
It’s a good idea to automate authorization testing in CI/CD pipelines to help catch regressions before code is deployed. For tests to be effective, they should check both what should be allowed (positive cases) and what should be blocked (negative cases).
6. Measure Developer Competence in Authorization Patterns
It’s useful for organizations to track whether developers can identify and fix broken access control vulnerabilities in practice. What’s important here is for teams to be able to demonstrate capability, rather than measuring how many courses have been completed.
Building Authorization Skills Across Development Teams
Working through broken access control vulnerabilities in real development environments helps developers recognize the same patterns when they show up in their own code. Passive training on its own doesn’t get the same results.
Effective training is continuous and measurable, and teams that practice regularly and have their progress tracked produce fewer authorization flaws in the long run.
SecureFlag’s ThreatCanvas helps teams model and document authorization requirements early in the SDLC, while its hands-on labs cover IDOR, BOLA, privilege escalation, and other authorization vulnerabilities across 70+ technologies.
Book a demo to see SecureFlag in action.
FAQs About Broken Access Control
What is the difference between broken access control and broken authentication?
Broken authentication involves failures in verifying user identity, including login flaws, weak session management, and credential stuffing. Broken access control is more about failures in enforcing what an authenticated user is permitted to access. You can have perfect authentication and still suffer from broken access control if authorization checks are missing.
Can static analysis tools reliably detect broken access control vulnerabilities?
Static analysis tools find it difficult to detect broken access control because they cannot understand application-specific authorization policies. They can report potential issues, such as missing checks before database queries, but cannot determine whether a given access pattern is actually permitted by business rules.
How does broken object-level authorization differ from insecure direct object references?
BOLA is the API-specific term for the same vulnerability pattern as IDOR. Both involve failing to verify that a user has permission to access a specific object identified by a user-supplied parameter. BOLA appears in the OWASP API Security Top 10, while IDOR is the traditional term from web application security.
