Broken Access Control and the Verification Problem
Broken access control lets a user read data or perform an action that should belong to another user, role, or organization. Common examples include changing an object identifier to read another account, crossing tenant boundaries, or calling an administrator endpoint as a regular user.
The category is common and consequential. In the OWASP Top 10 dataset, broken access control had more than 318,000 contributed occurrences and ranked first among web application risks. A 2026 study of 200 deployed vibe-coded applications found that broken access control represented 530 of 1,471 validated vulnerabilities—the largest category in the sample.
request · editable
sent you the merger deck — take a look
can you cover my shift saturday?
The people who message you show their handle (@bob, @charlie). The app only ever asks for your own inbox — the flaw is on the server, not the UI.
Why verification is different
Some vulnerability classes have broadly reusable verification rules. A SQL injection test can ask the database to delay a response. An XSS test can check whether a controlled script executes. The payload changes, but the property being tested is stable across applications.
Access control has no equivalent universal rule. If two users can read the same file, that may be a vulnerability, or the file may be public, shared, inherited through a team, or intentionally available to both users. The answer depends on the application's own entities and policies.
Asking a general-purpose model to decide intent does not solve the problem. A recent benchmark measured false-positive rates between 15% and 46% for frontier models on vulnerability classification. At production scale, even a small error rate creates more manual review than a security team can use.
Reconstructing an application-specific oracle
Wakefield starts by exercising the application through its normal interface with multiple authenticated accounts. The crawler records accessibility trees, HTTP requests and responses, identities, objects, and state changes. These observations are converted into an entity and relationship model.
Each successful user action supplies evidence for a policy. If a user can open a project through the interface, the model records the relationship that made the access valid: membership, ownership, role, tenant, or another observed condition. The result is a ReBAC-style graph derived from the running application rather than a generic authorization checklist.
Press Play to walk through how Wakefield crawls, discovers, and verifies.
During testing, agents propose actions that cross observed boundaries. The verifier replays the relevant state, checks the candidate against the reconstructed policy, and confirms whether the application permits an action that the model says should be denied. A report requires both the policy violation and repeatable application evidence.
What this approach does and does not prove
The model is only as complete as the workflows observed during crawling. Hidden features, unusual state transitions, and permissions that never appear in the interface can leave gaps. The interface itself can also expose behavior that was unintended by the developer. These are coverage limits, not reasons to replace verification with a model's opinion.
Source access can add useful evidence, but it is not required to construct the initial policy model. Combining black-box behavior with implementation details is a natural next step: runtime observations describe what the application permits, while source analysis can explain where that decision is enforced and how to fix it.