Why SAST misses broken access control, IDOR and business-logic flaws (and how AI review finds them)

Key takeaways

• Broken access control sits at the top of the OWASP Top 10, yet traditional SAST tools rarely catch it because an absent permission check leaves no unsafe syntax pattern to match.
• Detecting IDOR and privilege escalation requires knowing what a route is supposed to protect, how identity is bound to the session, and how sibling endpoints enforce access.
• Dokima maps attack surfaces, explicit security assumptions and trust boundaries before hunting specifically for authorisation and missing-control vulnerabilities.
• Because absence-of-control bugs do not have a single dangerous sink call, Dokima anchors their deduplication fingerprints to the protected asset and entrypoint.

Why does static analysis miss broken access control?

Broken access control, including insecure direct object references (IDOR), cross-tenant data leakage and privilege escalation, consistently ranks as the most prevalent critical vulnerability class in modern web applications and APIs. Yet engineering teams running traditional SAST tools in CI almost never see an alert for it.

The reason is fundamental to how rule-based static analysis works. SAST engines excel at finding presence vulnerabilities: places where code calls a known dangerous sink (such as exec(), eval(), raw SQL string concatenation or an insecure cipher) with tainted input.

Broken access control and business-logic flaws are usually absence vulnerabilities. The code that fetches a record from the database or mutates an account setting is syntactically clean, type-safe and uses parameterised queries. The vulnerability is what the code failed to check before running that query:

• Did the handler verify that the authenticated user belongs to the organisation that owns project_id?
• Can a user with the viewer role invoke a state-changing endpoint that was mounted on the general authenticated router instead of the admin router?
• Does a multi-step checkout or invitation flow allow the client to swap the target identifier between step one and step two?

A regex or abstract syntax tree (AST) rule cannot flag a missing requireOrgOwner() call unless it understands the domain model of your specific application.

What a real cross-file authorisation bug looks like

In production codebases, access control is rarely enforced in one uniform way. Consider a typical B2B service with four layers:

1. Router definitions (routes.go or app.ts): Attaches session middleware to route groups.
2. HTTP or RPC handlers (handlers/reports.go): Parses path parameters such as orgID and reportID.
3. Service layer (service/reports.go): Applies business rules and coordinates state changes.
4. Repository layer (store/sql.go): Queries rows by primary key (WHERE id = $1).

Suppose nine endpoints in handlers/ call s.requireMembership(ctx, orgID) before calling the store, or pass orgID into store.GetReportByOrgAndID(orgID, reportID). A tenth endpoint, added months later to download a report archive or revoke an installation, calls store.GetReportByID(reportID) directly after checking only that the user is signed in.

Every line of that tenth endpoint looks like valid, idiomatic code to a linter or SAST rule. Discovering the bug requires comparing the entrypoint, the session context, the sibling handlers and the store query across three files.

How Dokima maps security assumptions before hunting for auth bugs

If you ask an AI model to find access-control bugs without first establishing how the application handles identity, it will guess. It might flag internal CLI commands or background workers that are never exposed to untrusted users, while missing public HTTP routes.

Dokima solves this by running dedicated foundation stages before any vulnerability hunter runs:

1. Attack-surface and component mapping

The Repository Attack-Surface Mapper catalogues every external entrypoint (HTTP routes, gRPC methods, webhooks, WebSocket handlers, IPC sockets and CLI flags) and notes which authentication middleware wraps each group.

2. Explicit security assumptions

For each component, the Security Assumption Author writes concrete, testable statements about how the component expects callers to be authorised, and the Assumption Verifier tests whether those invariants hold in the code. For example: “All /org/{id}/* handlers verify that the authenticated session’s user ID is an active member of {id} before reading or mutating organisation state.”

3. Dedicated authorisation and missing-control lenses

Once that baseline exists, Dokima runs separate hunting stages focused specifically on Authorisation & Isolation, Trust-Boundary Violations, and Missing Security Controls. Instead of scanning for generic bad syntax, these stages inspect each entrypoint and state transition against the component’s security assumptions.

Eliminating false alarms with upstream trace verification

The main risk when hunting for missing authorisation checks is flagging a handler that is already protected by an upstream router, reverse-proxy rule or database row-level security policy.

Before Dokima promotes an access-control candidate to your report:

1. The Candidate Finding Peer Reviewer checks whether the hunter proved the full path from entrypoint to sink.
2. If middleware registration or store queries live in other files, the peer reviewer dispatches an Information Gatherer stage to read those exact files.
3. The Finding Validator confirms that an unprivileged or cross-tenant caller can actually reach the code path and trigger the unauthorised read or write.
4. For confirmed absence-of-control findings, Dokima’s deterministic fingerprinting anchors the finding identity to the protected asset and entrypoint so subsequent sweeps track the exact issue until it is fixed.

Using SAST and Dokima together

Fast syntax and dependency linters still belong in pull-request CI to block obvious mistakes in seconds. Dokima complements those checks by performing the deeper architectural and business-logic review that pattern matchers cannot express.

Explore the File Browser sample report to see real examples of validated authorisation, path-confinement and control-flow findings, or start a 21-day free trial on your own repositories.