In 2019, a real estate developer noticed something odd about a link he had received from First American Financial. The document ID in the URL was just a number. Change it, and a different customer's file appeared.
Those files included bank statements, Social Security numbers and driver's license images. According to SecurityWeek's reporting, roughly 885 million documents were reachable this way, with no login required. The incident later drew an investigation by the U.S. Securities and Exchange Commission.
No malware. No zero-day. Just a missing check. That is broken access control, and it remains the most common serious flaw in web applications today.
What broken access control actually means
Authentication answers the question "who are you?" Authorization, or access control, answers "what are you allowed to do?" Broken access control happens when an application lets a user read, change or delete something they should not be able to reach.
The OWASP Top 10 ranked it as the number one web application risk in 2021, and it held that position in the 2025 edition. The category also grew: server-side request forgery (SSRF) was folded into it, and it now explicitly covers API authorization failures known as BOLA and BFLA.
Real-world examples developers should know
First American Financial (2019). A classic Insecure Direct Object Reference, or IDOR. The server trusted the document number in the URL and never checked whether the requester owned that document.
Optus (2022). One of Australia's largest telecom providers exposed the personal data of about 9.5 million people. The Australian Communications and Media Authority alleged in court that a coding error made in 2018 left the access controls on a dormant API ineffective. The API later became internet-facing, and an attacker used it to pull customer records. Optus had reportedly fixed a similar issue on its main domain but missed the same problem on another one.
AI-built apps (2025). The Lovable vulnerability, tracked as CVE-2025-48757, left 170 generated apps without row-level access rules on their databases. We cover it in more detail in our article on AI-generated code security.
Different years, different industries, same root cause: the code worked, but nobody verified who was allowed to use it.
The patterns developers ship most often
-
IDOR and BOLA. Fetching a record by ID without checking that it belongs to the current user.
-
Missing function-level checks. Admin endpoints that are hidden in the interface but fully reachable by anyone who knows the URL.
-
Client-side enforcement. Disabling a button in the browser and assuming that is enough. Attackers do not use your buttons.
-
Forgotten endpoints. Old, test or internal APIs left exposed, as the Optus case showed.
-
Default allow. New routes that are open unless someone remembers to lock them.
Here is the IDOR pattern in a few lines of code. The difference is a single condition:
// Vulnerable: returns any invoice by ID
const invoice = await Invoice.findById(req.params.id);
// Fixed: only returns invoices owned by the logged-in user
const invoice = await Invoice.findOne({
_id: req.params.id,
ownerId: req.user.id
});
if (!invoice) return res.status(404).end();
How to train developers to prevent it
Broken access control is hard to catch with automated scanners because the code is not technically wrong. It just forgets to ask a question. That makes developer judgment the most important defense, and judgment is trained.
1. Teach the attacker's mindset first
Let developers exploit an IDOR in a safe lab before you explain the fix. Once someone has changed an ID and downloaded a stranger's data, they never look at a URL parameter the same way again.
2. Make deny-by-default the standard
Every new endpoint should require an explicit permission to be reachable. OWASP recommends enforcing checks on the server and using a single, reusable authorization layer instead of scattering checks across the codebase. The OWASP Authorization Cheat Sheet is a good team reference.
3. Write access control tests
Add tests that log in as user A and try to read user B's data. Add tests that call admin endpoints as a regular user. These are quick to write and catch regressions for good.
4. Add three questions to every code review
Who can call this? What can they access? Is that checked on the server? Simple questions, asked consistently, prevent most of the issues above.
5. Keep an inventory of your APIs
You cannot protect endpoints you have forgotten. Regularly review what is exposed and retire anything that is no longer needed.
Turn the lesson into hands-on practice
Simulations Labs lets you build labs and CTF challenges that recreate these exact scenarios: an IDOR in an invoice API, an unprotected admin route, a forgotten test endpoint. Developers exploit the flaw, then fix it, and you get analytics showing who has mastered access control and who needs more practice. Use the Simulations Copilot to select challenges around your own stack, or browse our setup guides to get your first event running.
The bottom line
Broken access control has topped the OWASP list for years because it is easy to introduce and easy to miss. The fix is not another tool. It is developers who instinctively ask who is allowed to do this. Get started for free and give your team a safe place to learn that instinct.
