Broken Access Control

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Access Control / Authorization
Typical Severity Critical
OWASP A01:2021 – Broken Access Control
CWE CWE-284 (Improper Access Control), CWE-285 (Improper Authorization), CWE-639 (IDOR)
Also known as Insecure Direct Object Reference (IDOR), Privilege Escalation, Unauthorized Access, Forced Browsing
Affected systems Web applications, REST APIs, mobile backends, admin panels, multi-tenant SaaS platforms

Overview

Broken Access Control is the #1 vulnerability category in the OWASP Top 10 (2021), appearing in 94% of applications tested. It encompasses any situation where a system fails to correctly enforce what actions a user is authorized to perform or what data they are authorized to access. Unlike authentication failures (which address who a user is), access control failures address what an authenticated — or even unauthenticated — user is allowed to do.

Access control vulnerabilities range from horizontal privilege escalation (accessing another user's data at the same privilege level) to vertical privilege escalation (accessing administrative or higher-privileged functionality), and include cases where unauthenticated users reach protected endpoints entirely.

How it works

Access control weaknesses arise when server-side authorization logic is absent, incomplete, or inconsistently applied. Common patterns include:

  • Insecure Direct Object Reference (IDOR): An API endpoint such as GET /api/invoices/4821 returns data based solely on the user-supplied ID without verifying that the requesting user owns or has rights to that invoice. An attacker enumerates IDs to access other users' records.
  • Forced browsing: Sensitive pages (e.g., /admin/dashboard, /reports/export) are reachable via direct URL navigation because the server only hides links in the UI rather than enforcing authorization server-side.
  • Missing function-level access control: An ordinary user discovers an administrative API endpoint (e.g., DELETE /api/users/:id) that lacks role checks and can call it successfully.
  • Client-side access control: Authorization decisions rely on hidden form fields, JavaScript flags, or JWT claims that the client can modify (e.g., changing "role":"user" to "role":"admin" in an unsigned or weakly signed token).
  • CORS misconfiguration: Overly permissive Cross-Origin Resource Sharing policies allow malicious third-party sites to make credentialed requests to authenticated endpoints.
  • Path traversal enabling access control bypass: URL manipulation such as /admin/../user/profile bypasses middleware that checks only the literal path prefix.
  • Metadata manipulation: Tampering with cookies, JWT tokens, or request parameters that control access level when the server trusts them without cryptographic verification.

Business impact

Successful exploitation of broken access control can have severe, multi-dimensional consequences:

  • Data breach: Attackers can exfiltrate personally identifiable information (PII), financial records, health data, or intellectual property belonging to other users or the organisation itself.
  • Data manipulation or deletion: Privilege escalation can allow modification or irreversible deletion of records, configurations, or user accounts.
  • Account takeover: Administrative functions exposed without proper checks allow attackers to reset passwords, change email addresses, or disable multi-factor authentication for any account.
  • Regulatory and legal liability: Exposure of user data violates GDPR, HIPAA, PCI-DSS, and similar frameworks, potentially resulting in significant financial penalties and mandatory breach notifications.
  • Reputational damage: Public disclosure of a data breach caused by access control failures erodes customer trust and brand value, often with lasting commercial impact.

How to fix it

  1. Enforce authorization server-side on every request: Never rely solely on UI-level hiding of links or buttons. Every API endpoint and server-rendered page must independently verify the requesting user's identity and permissions before returning data or executing an action.
  2. Adopt a deny-by-default policy: Access should be denied unless explicitly granted. New endpoints and resources should require positive permission grants rather than inheriting open access.
  3. Use indirect object references or GUIDs: Replace sequential numeric IDs with unpredictable identifiers (e.g., UUIDs) and always validate ownership or permission on the server when resolving any reference.
  4. Implement role-based or attribute-based access control (RBAC/ABAC): Define permissions centrally in a dedicated authorization layer or library. Avoid scattering ad hoc role checks throughout the codebase.
  5. Validate JWT tokens rigorously: Use strong, server-managed signing keys; validate the alg header; reject tokens with "alg":"none"; verify all claims including audience and expiry.
  6. Log and alert on access control failures: Record authorization denials with user identity, timestamp, resource, and action. Set up alerting for unusual patterns (e.g., repeated 403 responses from a single user).
  7. Write automated tests for access control: Include integration and regression tests that verify users cannot access resources or functions belonging to other users or higher privilege levels. Incorporate these into CI/CD pipelines.
  8. Review CORS policies: Restrict Access-Control-Allow-Origin to explicitly required origins; never use * with credentialed requests.
  9. Conduct regular access control reviews: Review permission matrices and access control logic during code reviews and periodically audit production configurations, especially after feature additions or refactoring.

Sensagraph automatically detects common broken access control indicators including exposed admin paths, IDOR-prone endpoint patterns, and overly permissive CORS configurations during continuous scanning.

References

Frequently asked questions

Authentication verifies the identity of a user (who you are), while access control — also called authorization — determines what an authenticated user is permitted to do or access. Broken access control vulnerabilities occur in the authorization layer, even when authentication is functioning correctly.

IDOR is a specific subtype of broken access control where an application exposes an internal object reference (such as a database ID in a URL like /invoices/4821) and fails to verify whether the requesting user is authorized to access that specific object. An attacker can manipulate the reference to access other users' data.

Horizontal privilege escalation occurs when a user accesses data or functions belonging to another user at the same privilege level (e.g., user A reading user B's profile). Vertical privilege escalation occurs when a lower-privileged user gains access to higher-privileged functionality, such as a regular user reaching administrative endpoints.

No. Client-side enforcement (hiding UI elements, using JavaScript flags, or relying on unverified tokens) is trivially bypassable. All access control decisions must be enforced server-side on every request, regardless of what the client presents in the UI.

Broken access control was promoted to the #1 position in the OWASP Top 10 2021 because it was found in 94% of applications tested, with over 318,000 occurrences of related CWEs. Its prevalence reflects both the difficulty of comprehensively implementing authorization logic across all application surfaces and the tendency to treat access control as an afterthought.