Testing Broken Access Control Without Guessing

Broken access control is a leading issue in the OWASP Top 10 for a decade, and automated tools struggle with this category more than any other. The problem lies in the fact that access control is not a single response pattern, but a relationship between two identities and one object. To test this, two accounts with identical roles and one shared object must be created.

Then, every endpoint can be walked using the first account's session and asserting on objects belonging to the second account. This method can be automated. The core of the testing process is simple: create two accounts, A and B, each owning one object, and then check every endpoint with A's session, asserting on objects belonging to B. To ensure the test is valid, the ownership must be established first by fetching B's object with B's token and recording a stable fingerprint.

The response must contain B's data, not just an empty array. Comparing the fingerprint against the response confirms the test's validity. Common mistakes include using non-existent ids, testing in the same tenant without different user accounts, trusting UI restrictions, ignoring export and report endpoints, and overlooking field-level filtering.

For GraphQL, two checks cover most cases: resolving a global ID with a different session and abusing batch/alias queries. Implementing this testing method in CI ensures that access control regressions are caught early, preventing them from being introduced by ordinary feature work.