As part of my journey into web security and penetration testing, I recently started learning about Broken Access Control through PortSwigger Web Security Academy. In this write-up, I'll share what I've understood so far, along with key concepts and practical insights.
What is Broken Access Control?
Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do.
In simple terms:
"Users can access data or perform actions they are not supposed to."
This is one of the most critical vulnerabilities and is ranked highly in modern web security risks.
Why is it Dangerous?
If access control is broken, attackers can:
- View other users' data
- Modify or delete sensitive information
- Perform admin-level actions
- Escalate privileges
Unlike some vulnerabilities, this doesn't always require advanced techniques — sometimes just changing a URL is enough.
Types of Access Control
While learning, I understood that access control is mainly divided into:
1. Vertical Access Control
- Restricts access based on user roles
- Example: Normal user accessing admin panel
2. Horizontal Access Control
- Restricts access between users of the same role
- Example: User A accessing User B's account
3. Context-Dependent Access Control
- Restricts access based on application state
- Example: Accessing a step in a workflow without completing previous steps
Common Vulnerabilities I Learned
1. Unprotected Admin Functionality
Sometimes admin panels are just hidden, not protected.
Example:
/admin /admin/deleteUser
If there's no proper authentication check → anyone can access it.
2. Parameter-Based Access Control
Applications may rely on parameters like:
?role=user ?isAdmin=true
If the server trusts these values → attacker can modify them and gain privileges.
3. IDOR (Insecure Direct Object Reference)
This was one of the most interesting parts.
Example:
/profile?id=123
If I change it to:
/profile?id=124
And I can see another user's data → Broken access control.
4. Missing Access Checks
Even if UI hides options, backend might not enforce it.
Example:
- "Delete user" button hidden for normal users
- But endpoint still works if accessed directly
My Hands-On Learning
While solving labs, I practiced:
- Modifying URLs
- Intercepting requests using Burp Suite
- Changing parameters
- Testing different user roles
This helped me understand that:
"Security should always be enforced on the server side, not just the frontend."
Key Takeaways
- Never trust client-side controls
- Always test endpoints directly
- Try horizontal and vertical privilege escalation
- Simple changes (like ID or role) can expose serious flaws