Broken Access Control

Massive bucket spanning unauthenticated-to-internal-resource leaks, role-bypass within multi-tenant apps, and admin-panel exposure. Top patterns:

• ..;/ and other traversal/normalization tricks bypassing front-door auth (Tomcat scripts, JBoss, WebLogic, IIS)
• header-based bypass - X-Forwarded-For: 127.0.0.1, X-Original-URL, X-Rewrite-URL, X-Custom-IP-Authorization to access internal-only endpoints
• low-privileged user invoking GraphQL mutations or REST endpoints meant for admins (Shopify staff with no permissions running billingChargesExport mutations, Rocket.Chat unauth Meteor methods)
• tenant cross-access - manipulating tenant id / org id / shop id in API calls returns other tenants' data
• admin panels publicly reachable (Spring Boot Actuator, JBoss management console, Jenkins script console, Solr admin, Kibana, MongoDB Express, ZooKeeper, RabbitMQ, Hadoop, Confluence /admin, Apache Druid console, Adminer, phpMyAdmin)
• Internal cron / debug routes exposed (/internal/, /private/, /admin/, /debug/, /metrics/) without IP allowlist
• signup bypass - directly hitting register endpoint or removing UI gating element to create internal-domain accounts (alerta.khanacademy via @khanacademy.org email)
• CORS misconfig allowing arbitrary origins to read responses with credentials
• authorization decision based on client-side flag, hidden form field, or cookie value the client controls
• outdated software with auth-bypass CVE (SAP RECON CVE-2020-6287, ColdFusion, Atlassian, Confluence). Many overlap with IDOR but here the resource itself is meant to be admin-only, not just object-bound.

• Apache Tomcat, JBoss, WildFly management consoles
• Spring Boot Actuator endpoints (env, heapdump, trace)
• Jenkins / Jenkins Script Console
• Solr / Kibana / Grafana / Prometheus admin
• Apache Druid / Apache Airflow / Apache Superset
• phpMyAdmin / Adminer / pgAdmin
• WordPress wp-admin / wp-json sensitive endpoints
• Shopify staff GraphQL endpoints
• Rocket.Chat / Mattermost / Slack-clone Meteor methods
• Multi-tenant SaaS APIs (Lark, Atlassian, GitLab) with org-scoped resources

• Append ..;/ ..%2F ..%2f..%2f ;/ /. to denied paths and check status differential
• Inject X-Forwarded-For: 127.0.0.1, X-Real-IP: 127.0.0.1, X-Original-URL: /admin, X-Rewrite-URL: /admin, X-Custom-IP-Authorization: 127.0.0.1
• Switch HTTP method (GET denied -> try POST/PUT/HEAD/OPTIONS/PATCH)
• Trailing slash, double slash, encoded slash, mixed case path tricks
• Replace tenant id / shop id / org id in URL/body with other tenant's id
• Probe GraphQL with anonymous and low-privilege sessions for admin-only operations
• Open dashboards and admin panels at canonical paths (/admin, /manager/html, /jmx-console, /actuator, /jolokia, /solr/, /kibana, /eureka, /h2-console, /env, /trace, /debug, /api/swagger)
• Sign up with internal email domain to inherit privileges (alerta-style)
• Modify role/perm claim in JWT and resubmit (algorithm none, weak HS256 secret)
• Call legacy or v1 endpoint when v2 is hardened

• GET /admin -> 401
• GET /..;/admin -> 200
• GET /admin/..;/admin -> 200
• GET /admin%2f -> 200
• GET /admin/. -> 200
• GET /admin// -> 200
• GET /Admin -> 200 (case bypass)
• GET /;/admin -> 200
• X-Forwarded-For: 127.0.0.1
• X-Real-IP: 127.0.0.1

For every URL that returned 401/403 in recon, retry with the path-trick variants (..;/, %2f, trailing-dot, trailing-slash, mixed-case, semicolon, encoded-slash) and compare response with the 401/403 baseline AND the homepage (require >100 chars and <85% similarity to baseline to flag - same false-positive guard as the existing 403_bypass module).

Replay every 401/403 with each of the X-Forwarded-For, X-Real-IP, X-Original-URL, X-Rewrite-URL, X-Custom-IP-Authorization, X-Forwarded-Host, Origin: null variants.

Retry GET-denied paths with POST/PUT/PATCH/HEAD/OPTIONS to detect verb-allowlist bugs.

Wordlist of /admin, /administrator, /manager/html, /jmx-console, /actuator/*, /jolokia, /solr/, /kibana, /eureka, /h2-console, /env, /trace, /debug, /api/swagger, /phpmyadmin, /adminer.php, /grafana, /metrics, /actuator/heapdump - content-validate each (must contain product-specific markers like 'Spring Boot Actuator', 'phpMyAdmin', etc.).

Replay sample auth requests with Origin: https://attacker.example and check Access-Control-Allow-Origin reflection plus Access-Control-Allow-Credentials.

When an authenticated session is provided, swap tenant id / shop id / org id in body or path and observe whether the response data corresponds to the other tenant.

If a GraphQL endpoint is detected, attempt a small set of admin-style operation names (billingChargesExport, addSamlProvider, livechatSaveOfficeHours, importGitHub) and observe responses.

Compose with Nuclei for SAP CVE-2020-6287, F5 CVE-2020-5902, Citrix ADC CVE-2019-19781, Confluence CVE-2022-26134, Atlassian-* etc.

Confidence: a content-validated bypass + difference from baseline = high; header-only bypass = medium; CORS-only = medium; CVE marker = high.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Path-trick bypass is the noisiest probe - most responses on ..;/ are catch-all 200 SPA pages or generic 404 templates.
• The existing bypass_403 module's content-similarity guard MUST be applied (require <85% similarity to homepage AND to original 403).
• Header bypass has a similar issue: many web apps reflect the IP without granting privileges; require the response body to differ from the baseline 401/403 (not just the header).
• Admin-panel sweep is high signal when content validators run - never trust 200 alone.
• CORS misconfig findings should be split: arbitrary-origin + credentials = critical; arbitrary-origin without credentials = informational.
• Tenant-id swap requires authenticated multi-account testing and is gated on the future authenticated-scan profile.

Manual Testing Methodology

Here is a systematic approach to identifying Broken Access Control vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Broken Access Control specifically, authenticate as a low-privilege test account, then substitute identifiers belonging to another account (sequential IDs, UUIDs harvested from other responses) into every request, and separately try reaching privileged endpoints/actions directly by URL or method regardless of what the UI exposes to that role.

Compare the response against your baseline, looking specifically for a 200 response containing another user's data, or a privileged action completing successfully, when the authenticated user should have received a 401/403 — compare against the expected-denial baseline for that same request from the same account.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Broken Access Control, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Broken access control and IDOR let attackers access or modify resources belonging to other users simply by changing an identifier, or by reaching an endpoint that should have required a higher privilege level. It's one of the most commonly reported vulnerability classes precisely because the underlying mistake is conceptually simple, yet easy to overlook in authorization logic that only checks whether a user is logged in, not whether they're entitled to the specific resource or action being requested.

Real-world exploitation ranges from reading other users' private messages, files, or financial records, to modifying account settings, to reaching admin-only functionality by requesting it directly regardless of what the UI shows. In multi-tenant applications, it can mean cross-tenant data access entirely. The severity scales directly with how sensitive the exposed resource or action is.

This bug class shows up in virtually every kind of application, from social platforms to banking APIs to healthcare systems, which makes it one of the more consistently valuable checks to run regardless of what the target actually does — and one of the hardest for an automated scanner to catch reliably, since confirming it requires understanding what a specific user should and shouldn't be able to reach.

Prevention and Secure Coding

Preventing Broken Access Control takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Object-level authorization on every request. Verify the authenticated user actually owns or is entitled to the specific resource identified in the request — on every endpoint that accepts an identifier, not just the ones that seemed sensitive during development.

Centralize the authorization logic. Implement authorization checks in one shared layer or middleware instead of re-implementing them per endpoint; re-implementation is exactly where individual endpoints get missed.

Default-deny. Require an explicit permission grant for each action a role can take, rather than granting broad access and trying to enumerate exceptions.

Indirect references where feasible. Opaque, per-user tokens in place of sequential database IDs make horizontal enumeration harder, though this is a hardening measure, not a substitute for the authorization check itself.

Test authorization from the attacker's seat, not the developer's. Authenticate as a low-privilege user and attempt every action a higher-privilege or different-tenant user could take — the UI hiding a button is not an authorization control.