What Is Broken Access Control and How Do You Prevent It?
A user signs into your web application and sees their own account. Then one of them edits a number in the address bar and sees another person’s account instead. No password broke. No malware ran. The application skipped the one check for whether the request belonged to the person making it. This failure has a name, broken access control, and OWASP ranks it as the top web application security risk. Across the applications OWASP studied, 94 percent showed some form of it.
Access control decides what each user is allowed to do once they are inside your application. Authentication proves who someone is. Authorization decides what they reach. Broken access control is the breakdown of the second step. The person is known to the system, but the application never confirms their action fits their permissions. So a regular user reaches an admin page, reads another customer’s records, or deletes data they were never meant to touch. The Canadian Centre for Cyber Security points software builders toward enforcing authorization inside the code itself, in its joint guidance on a software security code of practice. The control belongs in your application logic, not in the hope no one looks.
How broken access control shows up
The most common form is an insecure direct object reference, known as IDOR. Your application puts a record number in a URL or a form field, like an invoice ID or an account number. The attacker changes it and reaches a record owned by someone else. A second form is privilege escalation. A standard user calls an administrative function, or an unauthenticated visitor reaches a page meant for logged-in staff. A third form is a missing check on an API. The web page hides the delete button from ordinary users, but the API behind it accepts a delete request from anyone who sends one. Each case shares a single root. The application trusts the request instead of verifying the requester.
What one skipped check costs Canadian organizations
Statistics Canada reported in October 2026 a national rate of 16 percent. One in six Canadian businesses took a cyber security incident during 2025. Among the businesses attacked, intruders exploited software, hardware, or network weaknesses in 23 percent of cases, the agency’s latest cyber security and cybercrime figures show. Canadian firms spent an average of 54,772 dollars on prevention the same year. Broken access control sits squarely in the weakness category, and it rarely leaves the loud evidence a ransomware note leaves. An attacker reads records through a flaw in your own authorization logic and walks away quietly, which is why many access control breaches surface only once the stolen data appears elsewhere.
Why OWASP moved it to the top
Broken access control climbed from fifth place to first in the OWASP Top 10. It carried more occurrences than any other category, 318,487 across the contributed data, mapped to 34 separate weakness types. The reason is plain. Access control runs through every feature in an application. Each new page, report, and API call needs its own authorization check, and a single missing one opens a door. Attackers know this, so they test every identifier, parameter, and endpoint your application exposes. You defend by treating each request as hostile until your code proves the requester holds the right.
How you prevent broken access control
Start with deny by default. Every resource stays closed unless a rule opens it for a named role, with public pages the only exception. Enforce the decision on the server for every request, never in the browser, where a user rewrites anything. Check ownership on each record, so the system confirms the invoice belongs to the account asking for it rather than serving any ID handed over. Build your access control logic once, in a shared component, and call it everywhere, rather than rewriting the check in each feature where one gets forgotten. Apply least privilege across roles, giving each account the narrowest set of rights its job needs.
Layer monitoring and limits on top of the code. Log every access control failure and alert your team when the failures cluster, since a burst of denied requests often marks an attacker probing identifiers. Rate limit your APIs so automated tools never cycle through thousands of record numbers in minutes. Invalidate sessions in full at logout and keep any token short-lived. Write automated tests for your authorization rules and run them with every release, because access control breaks quietly the moment a developer ships a new endpoint without the check. The OWASP entry on broken access control sets out these controls in full, and they map cleanly to the access control families in Canada’s ITSG-33 and the CCCS Baseline Cyber Security Controls.
Build the team who closes these gaps
Tools flag some broken access control. Trained people design it out. The Certified Secure Web Application Engineer path teaches developers to enforce authorization on the server, check record ownership, and deny by default from the first line of code. The Certified Web Security Engineer track carries the skill across the full application stack. On the offensive side, the Certified Professional Ethical Hacker program shows your testers how attackers walk through IDOR and privilege escalation flaws. The Certified Penetration Testing Engineer path drives the testing deeper with hands-on labs against live targets. Mile2 ties each course to a working role, so your people apply the skill the week they finish.
Broken access control survives because applications trust the request and skip the check behind it. The fix sits inside your reach. Deny every action by default, confirm authorization on the server for each request, enforce record ownership, and test the rules on every release. Then put trained developers and testers on the work so the gap never ships. OWASP placed this flaw at the top for a reason. Attackers probe Canadian applications daily for the next identifier left unguarded. Close it first, and the changed number in the address bar returns nothing.
