Broken access control is a security vulnerability that occurs when restrictions on user permissions fail, allowing unauthorized users to access sensitive data or perform actions they shouldn’t be able to. This can lead to serious consequences, such as data breaches, unauthorized modifications, or even complete system takeovers.
Some common examples of broken access control include:
To prevent broken access control, organizations should enforce strict access policies, implement least privilege principles, and ensure proper authentication mechanisms. Want to dive deeper into how companies tackle this issue?
Broken Access Control happens when a web application or system doesn’t properly check what a user is allowed to do. This means users can access data or perform actions that should be restricted.
A user initiates a request to the application, such as accessing a page, modifying data, or invoking a specific function.
The application should validate the user’s permissions to ensure they are authorized to perform the requested action (e.g., verifying if the user is an admin or if they own the resource being accessed).
If the application fails to enforce these checks — or implements them incorrectly — unauthorized access becomes possible.
As a result, users may be able to:
View or modify data that belongs to other users
Access administrative interfaces or functions
Delete resources they do not own
Escalate their privileges (e.g., promote themselves to an admin role)
The Normal User Visit:
/account/123
They change the URL to:
/account/124
Broken Access Control vulnerability — specifically demonstrating an Insecure Direct Object Reference (IDOR), which is one of the most common forms.
A web application allows users to view their profile by visiting:
GET /user/profile?id=1001
there’s no server-side check to ensure the user is only accessing their own profile.
Steps to Exploit:
Login as a normal user (e.g., UserA, who has ID 1001)
Intercept a request to view your own profile:
GET /user/profile?id=1001
Modify the id parameter in the URL or request:
GET /user/profile?id=1002
Response:
If the server returns the profile data of another user (e.g., UserB with ID 1002), access control is broken.
GET /user/profile?id=1002 HTTP/1.1
Host: vulnerable-app.com
Cookie: session=eyJhbGciOiJIUzI1NiIsInR5cCI6...
Expected (Vulnerable) Response:
{
"id": 1002,
"username": "user_b",
"email": "user_b@example.com",
"balance": "$3,000"
}
Broken Access Control comes in many forms, depending on how permissions are mismanaged. These flaws can let attackers read, modify, or delete data they shouldn’t touch — or even escalate to admin.
The application exposes a reference to internal objects (like user IDs or file names), but fails to verify authorization
GET /invoices/123.pdf
changing it to: –
GET /invoices/124.pdf
A lower-privileged user accesses admin-level functionality.
Example:
A regular user sends a request to:
POST /admin/deleteUser?id=10
One user accesses another user’s data at the same privilege level.
Example:
Viewing another user’s account details, messages, or files.
Accessing unauthorized pages or functions by guessing or navigating to hidden URLs.
Example:
Accessing:
/admin/panel
The backend doesn’t enforce role checks for sensitive actions.
Example:
The frontend hides a button from regular users, but they can still send a direct request to the endpoint and the backend lets them.
Access control rules are not applied or turned off, often during development or by misconfiguration.
Example:
An API endpoint is accidentally left open to the public with no authentication.
The frontend enforces access control (e.g., hiding buttons), but the backend trusts the client blindly.
Example:
A user modifies JavaScript in the browser to unhide restricted actions or sends crafted requests using tools like Postman.
Accessing unauthorized files on the server.
GET /download?file=../../etc/passwd
This would describe a situation where access is controlled based on user input in the URL or parameters (reflected client-side), without verifying permissions on the server.
Example:-
GET /admin/dashboard?role=user
If the app denies access just because role=user was in the URL — but doesn’t check the actual session or backend permissions, this is insecure. The attacker can change the value to:
GET /admin/dashboard?role=admin
If you meant: – The system correctly denies access and shows a message — Access Denied” Then this is not a vulnerability. It’s an example of access control working properly.
GET /admin/settings
If you’re not an admin, the server returns:
HTTP/1.1 403 Forbidden
{
"error": "Access Denied"
}
Read More :
What happened: The WordPress plugin “WP Event Manager” (version ≤ 3.1.47) had a severe Missing Authorization issue, allowing unauthenticated users to perform restricted actions due to improperly configured access levels
Risk level: Common Vulnerability Scoring System (CVSS) score indicates high impact with no required privileges. Read more
Impact: Attackers could execute events-related functions (like editing/deleting listings) without proper role validation.
Status: The vulnerability was publicly reported on April 4, 2025—version 3.1.47 and earlier are affected. A patch has been issued; users must update promptly.
What happened: The open-source “IcProgress Innovación y Cualificación” plugin exposed sensitive user data—like IP addresses and user messages—due to insufficient access restrictions github.com.
When: Published in early 2025.
Impact: Any logged-in user could access other users’ data, violating privacy and confidentiality.
Mitigation: Site administrators should uninstall or patch the plugin and audit other plugins for similar faults.
What happened: In mid‑2024, attackers gained unauthorized access to multiple organizations’ Snowflake cloud instances by exploiting weak credential security and missing MFA enforcement Read more
Impact: Over 160 customer environments—including AT&T, Ticketmaster, Santander—were accessed improperly Read More
Root cause: Lacked strong access controls like enforced MFA and proper session verification.
Lesson: Even secure platforms can be exposed when tenant-level access control and credential hygiene fail.
1). Always deny access by default and only allow actions explicitly authorized.
2). Enforce all access control checks on the server side, not the client side.
3). Use centralized access control logic to ensure consistent permission enforcement.
4). Implement Role-Based or Attribute-Based Access Control to manage user permissions clearly.
5). Avoid using predictable IDs in URLs; use UUIDs or secure tokens instead.
6). Secure all API endpoints with proper authentication and authorization mechanisms.
7). Regularly test for access control flaws using tools like Burp Suite or OWASP ZAP.
8). Log and monitor unauthorized access attempts to detect misuse or intrusion.
9). Apply rate limiting to prevent brute-force and enumeration attacks on endpoints.
10). Conduct periodic access reviews to ensure roles and permissions remain appropriate.
Signup our newsletter to get update information, news, insight or promotions.
Copyright 2025 © Hackanics
