Broken Access Control and Data Exposure

Broken access control and excessive data exposure are among the most common and damaging API vulnerabilities. Even when authentication works, APIs may still reveal data or allow actions to users who should not have them. Security-conscious API testing must actively probe these boundaries.

Access Control and Data Exposure in APIs

Access control covers both vertical permissions (what roles can do) and horizontal permissions (which resources a user can access). Data exposure focuses on which fields and relationships are returned in responses. APIs that expose more data than necessary, or that fail to check ownership and roles carefully, create opportunities for attackers.

# Example access control test ideas

- User cannot access another user's orders.
- Support role can view but not modify certain resources.
- Admin endpoints are inaccessible to non-admin tokens.
- Responses omit sensitive internal fields not needed by clients.
Note: Many breaches stem from simple IDOR (Insecure Direct Object Reference) issues, where changing an ID in a request reveals another user’s data.
Tip: Use multiple accounts and tokens to systematically test cross-user and cross-tenant access, not just your own account.
Warning: Relying only on UI-based checks is dangerous; APIs must enforce access control even when called directly.

Data exposure tests check that responses do not inadvertently include fields such as internal IDs, debug flags, configuration data, or full personal details when not required. API designers should follow the principle of least privilege and minimal data by default.

Systematic Access Control Testing

Design test matrices that combine roles, resource types, and operations (create, read, update, delete). For each combination, define the expected outcome and implement tests that verify it. Automation can help cover many combinations, but even manual spot-checking can reveal glaring issues.

Common Mistakes

Mistake 1 โ€” Testing access only with a single privileged account

This hides privilege escalation paths.

โŒ Wrong: Using only admin tokens in tests because it is convenient.

โœ… Correct: Use separate identities per role and test both allowed and forbidden actions.

Mistake 2 โ€” Ignoring what data is returned, focusing only on status codes

Sensitive fields can leak even when access appears controlled.

โŒ Wrong: Treating any 200 response as acceptable without inspecting the payload.

โœ… Correct: Review response bodies for excess or unintended information.

🧠 Test Yourself

What is the main testing objective for broken access control and data exposure?