exploiting-broken-access-control

Confirms BFLA and IDOR vulnerabilities by firing authenticated HTTP requests against staging targets.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/bs-koo/gx-security --skill exploiting-broken-access-control-bs-koo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: exploiting-broken-access-control
Source: https://github.com/bs-koo/gx-security/tree/main/skills/exploiting-broken-access-control
Command: npx skills add https://github.com/bs-koo/gx-security --skill exploiting-broken-access-control-bs-koo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Static scanners flag broken access control candidates (BFLA/IDOR) but cannot prove exploitability, producing false positives. This Skill dynamically fires real requests against a running staging or local target to confirm or refute each candidate using HTTP status codes. ## Core Features & Use Cases - BFLA verification: Calls admin APIs (e.g., /adm/v1/users) with a normal user token and compares against anonymous access to detect missing role checks. - IDOR verification with false-positive refutation: Accesses user A's resource with user B's token; an HTTP 403 response immediately confirms the static finding was a false positive. - Fail-closed safety gate: Enforces scope_guard validation before any request, blocking production or public targets at the code level, with GET-only non-destructive testing by default. - Use Case: After a static scan flags @PathVariable id endpoints as IDOR candidates, run this Skill against localhost with two test accounts to dynamically prove which endpoints actually leak other users' data. ## Quick Start Run the access-control penetration test against my local staging app at http://localhost:7171 using the static scan results and my two test accounts to confirm which BFLA and IDOR candidates are actually exploitable.

Frequently Asked Questions about exploiting-broken-access-control

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for IDOR vulnerabilities in a web application?▼

Create two test accounts, have account A own a resource, then request that resource with account B's token. An HTTP 2xx response confirms IDOR exposure, while 401 or 403 confirms proper authorization defense.

How do I verify BFLA broken function-level authorization?▼

Call admin API endpoints such as /adm/v1/users using a normal user token instead of an admin token. If the server returns 2xx while anonymous requests are rejected, role validation is missing and the endpoint is vulnerable.

Can this tool test production websites for access control flaws?▼

No. The scope_guard safety gate blocks production, public, and IP-spoofed targets at the code level before any request is fired. It only runs against authorized staging or local environments with the --authorized flag.

Why does a static IDOR finding turn out to be a false positive?▼

Static scanners flag @PathVariable id patterns but cannot see domain-layer defenses like validateOwner methods. When dynamic testing returns HTTP 403, the domain layer blocked the request, so the static High finding is confirmed as a false positive.

Does the access control test modify or delete data on the target?▼

No, it is non-destructive by default and only fires GET requests to prove authorization bypass through data reads. Write operations like PUT or DELETE require an explicit --allow-destructive flag plus human approval, and are not yet implemented.