What does OWASP A5 (Broken Access Control) look like in practice, and how do you fix it?

Broken access control = authorisation checks missing, only client-side, or bypassable by URL/parameter tampering. Fix: deny-by-default + always check server-side + indirect references.

Classic symptoms:

• Restricted resources accessible by typing the URL directly (no auth check on that endpoint).
• Seeing other users' data by changing a user-ID parameter in the URL (IDOR — Insecure Direct Object Reference).
• Database rows visible by changing the primary-key parameter.
• "Hidden" functions only hidden client-side — visible in browser dev tools, easily called via curl.
• Access checks only run in the browser — bypassed by sending the API request directly.

Counter-measures:

• Always check rights server-side. Never trust the client.
• Central authorisation tool — one place where all permissions are checked and administered; not scattered ad-hoc through the codebase.
• Deny by default — the absence of an explicit "allow" rule means "deny", not "allow". This is fundamental.
• Least privilege / need-to-know / need-to-have — grant the minimum rights required.
• Indirect object references — instead of /api/user/12345/document/789 (where 789 is a primary key), use /api/user/12345/document/abc-xyz-… (an opaque token mapped server-side). Reduces IDOR risk.
• Check rights at every workflow step — don't trust that "the user got here, so they must be authorised" — re-verify at each action.

Tip: the OWASP Access Control Cheat Sheet has the practical implementation guidance.