detecting-broken-access-control

Detects IDOR, BFLA, and forced browsing vulnerabilities in Spring Boot and JSP web applications.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve? Web applications often expose endpoints where users can access other users' data by manipulating ID parameters (IDOR), call admin APIs without proper role checks (BFLA), or reach protected pages by typing URLs directly (forced browsing). Manual review of every controller and interceptor for these access control flaws is slow and error-prone, especially across mixed Spring Boot and legacy JSP codebases. ## Core Features & Use Cases - Hybrid static detection: Runs Semgrep rules (with a grep fallback) to broadly flag candidates such as @PathVariable IDs without ownership checks, admin controllers missing @PreAuthorize, anyRequest().permitAll() gaps, and AuthInterceptor mode=off/audit. - AI context verification ladder: Each candidate is judged secure, vulnerable, or needs-runtime by tracing ownership enforcement from controller through service to the domain layer, reducing false positives from rich-domain patterns like validateOwner(). - Stack auto-detection: Distinguishes spring-modern (JWT, WebSecurityConfig) from jsp-legacy (eGovFrame session, AuthInterceptor) and applies stack-specific rules and verification points. - Use Case: Point the scanner at a Spring Boot project and receive a severity-ranked report where each confirmed BFLA or IDOR finding includes the vulnerable code location, why it is exploitable, a conceptual proof of concept, and a concrete fix such as adding @PreAuthorize. ## Quick Start Run the access control scan on my project source directory and produce a report of confirmed IDOR and BFLA vulnerabilities with file and line evidence.

Frequently Asked Questions about detecting-broken-access-control

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

FAQPage Schema
How do I detect IDOR vulnerabilities in a Spring Boot application?▼

Scan the source with Semgrep rules that flag @PathVariable ID parameters lacking ownership checks, then verify each candidate by tracing whether the service or domain layer scopes queries to the authenticated principal. Confirmed cases are reported with file, line, and a fix such as comparing the session user ID against the resource owner.

What is BFLA and how is it detected in admin controllers?▼

BFLA (Broken Function-Level Authorization) occurs when authenticated users without admin roles can call admin APIs. It is detected by finding @RequestMapping paths under /adm/** whose controllers lack @PreAuthorize or @Secured annotations, since URL-level authenticated() checks alone do not enforce roles.

Does the scanner work without Semgrep installed?▼

Yes, the scan script falls back to regex-based grep detection when Semgrep is unavailable. The fallback has lower precision and recall, so it emits a warning and relies more heavily on the AI context verification step to filter false positives.

Can it analyze legacy JSP and eGovFrame applications?▼

Yes, it auto-detects the jsp-legacy stack via web.xml and JSP files, then checks AuthInterceptor mode settings, getParameter-based ID lookups without ownership validation, AuthUtil.isAdmin null-safety, and whether the DB-driven URL security rule table is actually populated.

Why does the skill avoid confirming IDOR from static analysis alone?▼

Ownership enforcement may live in domain methods like validateOwner() or in dynamic policy layers that static analysis cannot see. Candidates are judged secure, vulnerable, or needs-runtime, and needs-runtime items are escalated to dynamic two-user proof-of-concept testing before being rated High.