Broken Access Control and IDOR Vulnerabilities

Access control decides who is allowed to do what inside an application. When those decisions are missing, incomplete, or enforced only in the browser, the flaw is called broken access control. It sits at the very top of the OWASP Top 10 because it is both extremely common and directly damaging: a single missing check can expose every user's private data.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

This lesson focuses on the most frequent form, Insecure Direct Object Reference (IDOR), where the server trusts an identifier supplied by the client without confirming the caller owns that object. Understanding this pattern matters because the fix is conceptual, not cosmetic: authorisation must be re-verified on the server for every request, never assumed from a hidden field or a disabled button.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.