TL;DR

Prime Big Deal Days · Oct 6–7Offer from Amazon

Get privacy and security gear delivered free — and shop member deals

• Fast, free delivery on millions of items
• Access to Prime Big Deal Days deals on October 6–7
• Prime Video, Amazon Music and more included

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

Broken access control happens when an application fails to enforce what a user is allowed to see or do — for example, changing an invoice ID in a URL returns someone else’s data. OWASP ranked it the #1 web application security risk in 2021, and its API Security Top 10 (2023) lists related flaws like Broken Object Level Authorization. The fix is server-side, deny-by-default authorization checks applied to every request, across every interface.

A customer logs in with a perfectly ordinary account, changes one number in a URL, and suddenly reads another customer’s invoices. No hacking tools. No stolen passwords. The application simply forgot to ask one question: is this person allowed to see this record?

That’s broken access control, and according to OWASP’s 2021 Top 10, it’s the single most common critical web application security risk — ranked above injection and cryptography failures [1]. It happens when an application fails to enforce what a user is permitted to access or do.

In this article, you’ll learn what broken access control actually looks like in real products, why it’s so easy to miss, and how a small authorization gap becomes a real business problem: breach notifications, fraudulent transactions, investigations, and customers who quietly take their business elsewhere.

What Broken Access Control Really Means (In Plain English)

Broken access control is a failure to enforce the rules that determine which users can access particular data or perform particular actions. The user logs in successfully. The application trusts them too much after that. They can view another person’s records, perform a role they don’t hold, or reach admin functions just by changing a URL, a request parameter, or an API call [1].

Here’s the distinction that trips up even technical teams: authentication is not authorization. Authentication answers “who are you?” Authorization answers “what are you allowed to do?” A valid login proves identity. It does not justify every request that follows. Treating those two things as the same is like a hotel checking your passport at the front desk, then letting you walk into any room in the building because you’re “a verified guest.”

The most common flavor is called an insecure direct object reference, or IDOR. The app exposes an identifier — an invoice number, an account ID, a document ID — and never checks ownership. Change the number, receive someone else’s data. Security researchers find these constantly because the attack is almost embarrassingly simple.

And remember: access control covers actions, not just data. A user who can view a record may have no business editing it, approving a payment, exporting a dataset, or changing account settings. Each of those is a separate permission the server must verify.

The Attack Chain: How One Ordinary Account Becomes an Incident

The chain from flaw to business problem is usually short and boring — which is exactly why it works. An attacker signs in with a normal account, discovers one request the application doesn’t properly restrict, and uses it to access or alter something outside their permissions [1].

Imagine a small business banking portal. Every payment approval page loads a URL like /approvals/8823. A curious account holder changes it to /approvals/8822 and sees a pending wire transfer belonging to a completely different company. Now scale that: an automated script walking through ten thousand IDs overnight. By morning, one low-privilege account has harvested an entire customer database — names, bank details, transaction histories.

Or take the function-level version. A customer service dashboard hides the “refund customer” button from junior agents. But the underlying API endpoint still accepts the request. Someone who reads the app’s JavaScript — which anyone can do — finds the endpoint, calls it directly, and issues refunds at will. The hidden button was never a security control; it was decoration.

This is why broken access control is a vulnerability, not automatically a breach. A breach is what happens if someone exploits the flaw and actually reaches protected data or performs unauthorized actions. The gap sits quietly until the day someone walks through it — and in many real incidents, the intruder looks identical to a legitimate user in the logs.

Why Hiding Buttons and Menus Doesn’t Stop Anyone

Hiding a page, button, or menu item doesn’t stop anyone because a user can often call the underlying endpoint directly. The interface is a suggestion; the server is the enforcement point. If the server doesn’t check permission when the request arrives, the check doesn’t exist [1].

Think of it like a shop with a door marked “staff only” that isn’t actually locked. Painted signs deter honest people. They deter nobody else. Modern applications make the unlocked-door problem worse: the same data is reachable through a web app, a mobile client, an API, a cloud integration, and maybe an admin console. A policy correctly enforced in the web interface can be missing entirely from an API endpoint that serves the same records [1].

Multi-tenant products add another layer. With multiple customer organizations sharing one platform, delegated access, and temporary privileges, permission rules get complicated fast — and every inconsistency is a gap. When roles, business processes, or integrations change, old permissions often survive like leftovers nobody cleared out.

• Client-side checks are UX, not security. They improve the interface; they protect nothing.
• Every interface needs the same policy. Web, mobile, API, and admin paths must all enforce identical authorization rules.
• Complexity is the enemy. More roles, tenants, and integrations mean more places a check can be forgotten.

What It Actually Costs: The Real Business Bill

The business problem isn’t the technical fix — a missing ownership check might take a developer an afternoon to patch. The bill comes afterward, and it keeps growing long after the code is fixed [1].

Start with the immediate response: figuring out what was accessed, involving legal and compliance teams, restoring or validating data, and answering customer questions. Then the obligations. If health, financial, employee, or customer data was exposed, you may need to notify affected people and demonstrate corrective action to regulators. The exact duties depend on the data, the jurisdiction, and the circumstances — but privacy regimes like GDPR and HIPAA don’t care whether the attacker “hacked” you or simply edited a URL.

Then there’s the part no spreadsheet captures. Unauthorized changes can hit revenue directly: fraudulent refunds, tampered orders, corrupted records. Operational disruption follows. And customer confidence is slow to rebuild — enterprise customers especially will ask hard questions in the next procurement cycle. One broken access control flaw can become a real business problem measured in legal fees, churn, and a quarter of engineering time spent on forensics instead of product.

A missing authorization check is cheap to fix before deployment and expensive to fix after someone notices it. The cost difference is the entire incident.

How to Reduce the Risk: A Practical Checklist

You reduce the risk of broken access control by enforcing authorization on the server side, for every request, denying by default and granting only what each role needs [1]. That sentence is the whole philosophy. Here’s how to put it into practice.

1. Enforce authorization server-side, on every request. No exceptions for “internal” endpoints or requests that “shouldn’t happen.”
2. Check the action AND the resource. Verify both that the user may perform the operation and that they own or are entitled to that specific record.
3. Deny by default. Access is closed until a rule explicitly opens it — never the other way around.
4. Apply one consistent policy everywhere. Web, mobile, API, and admin interfaces must share the same authorization logic, not parallel implementations that drift apart.
5. Test with different roles and accounts. Actively try to access another user’s or another tenant’s records during testing, not just the happy path.
6. Log sensitive access and privilege changes. You’ll need those logs to answer “what did they touch?” — while collecting only what you need.
7. Review permissions when things change. New roles, new integrations, new business processes — each one is a moment to audit what access still makes sense.

Notice what’s missing from that list: expensive tooling as a silver bullet. These are habits, not products. A team that asks “who is allowed to do this?” for every endpoint, every time, has already solved most of the problem.

Vulnerability vs. Breach: What a Flaw Means for Reporting

Finding a broken access control flaw does not automatically mean you must report a breach. Reporting duties depend on whether protected data was actually accessed or exposed, what data was involved, and the rules that apply in your jurisdiction [1]. A flaw should still be investigated promptly — assuming the best is how small gaps become front-page incidents.

If you do find a flaw, work the sequence in order:

1. Restrict or disable the affected path if needed to stop ongoing abuse.
2. Investigate logs and scope — what could have been reached, and was it actually reached?
3. Fix the authorization checks properly, not just the symptom.
4. Assess impact on data and business actions.
5. Follow applicable legal, contractual, and customer-notification processes.

One more caution for the modern stack: as teams add AI features and automated agents, the same principle applies unchanged. Every user, service, and agent acting in your system must be limited to what its identity permits — an over-privileged automation script is just an IDOR with a new job title [1].

Frequently Asked Questions

What is broken access control?

Broken access control is a failure to enforce the rules that determine which users can access particular data or perform particular actions. A user may view another person’s records, perform a role-restricted action, or reach administrative functions simply by changing a URL, request parameter, or API call [1].

Is broken access control the same as IDOR?

No. IDOR (insecure direct object reference) is one common example of broken access control. It occurs when an application exposes an object identifier — like an invoice or account ID — but fails to check whether the requester is authorized to access that object [1].

Can a legitimate, logged-in user exploit broken access control?

Yes. Many real cases involve a valid, low-privilege account accessing another user’s records or functions reserved for higher-privilege roles. This is precisely why authentication alone isn’t enough — every request must also pass an authorization check [1].

Does discovering an access control flaw mean we have to report a data breach?

Not automatically. Reporting obligations depend on whether protected data was actually accessed or exposed, what data was involved, and the applicable rules in your jurisdiction. A flaw should still be investigated promptly — check logs for actual access, fix the authorization checks, and follow legal and contractual notification processes as needed [1].

Why isn’t hiding a page or button enough protection?

Because a user can often call the underlying endpoint directly, bypassing the interface entirely. Hidden buttons are user experience design, not security controls. The server must check permission when each request arrives [1].

What are the warning signs of broken access control?

Common signs include users able to view or change records belonging to others, perform actions outside their role, reach restricted administrative functions, or cross boundaries between customers or tenants in a multi-tenant product. Test for these deliberately with multiple accounts during development [1].

Conclusion

Broken access control becomes a real business problem through one simple mechanism: an application works perfectly for legitimate users while never verifying that each request is authorized. One ordinary account plus one unchecked ID equals one incident report. The defense is equally simple to state and disciplined to practice — the server asks “is this allowed?” on every single request, denies by default, and applies the same rules everywhere.

Ask yourself this before your next release: if a curious customer changed one number in a URL tomorrow morning, what would they see? If you don’t know the answer with certainty, that’s the place to start.