Write the permission rule before the test
Authorization testing starts with a product rule, not a request tool. Identify the actor, action, resource, and organization involved. For a document service, a rule might say that workspace members can read shared documents while only their owners can delete them. Record exceptions for administrators, guests, suspended users, and invited users before deciding what a successful test means.
An example permission matrix can use two workspaces, two ordinary members, and one administrator. For each role, document whether reading, editing, exporting, and deleting a sample record is allowed. Use a staging environment and synthetic records so a failed permission check does not expose customer information. This guide describes testing your own application or an explicitly authorized environment.
Check identity, object ownership, and tenant membership separately
Authentication establishes the identity behind a request. Object-level authorization determines whether that identity can access the requested record. Tenant authorization adds the organization boundary. A route can correctly require a session and still return a document from a different workspace because its database lookup checks only a document identifier.
Review list, detail, update, export, attachment, and background-job endpoints. Applying a workspace filter to the list screen does not automatically protect a separate download route. A job created by one tenant should not later become readable by another tenant merely because its status endpoint accepts a job identifier. Include indirect references such as share links and file storage paths.
Run a controlled review with accounts you own
Create a record as test account A. Confirm that A can perform the intended operation. Then use test account B, whose documented permissions exclude that record, and request the same operation through the supported test interface or API client. Check both the response and its side effects: a denied response is insufficient if a write already occurred.
Use only known identifiers for your synthetic records. There is no need to enumerate other users or retrieve real customer data. Repeat the check with no session, an expired session, a different tenant, and a role whose privileges have just been removed. For destructive operations, use disposable fixtures and confirm cleanup. A denial can use different status codes depending on the application; the essential outcome is that unauthorized data and actions remain inaccessible.
Worked example: a cross-workspace document boundary
This is a synthetic teaching example, not a WarHound AI finding or a test of a real customer application. In a staging document service, Alice belongs only to Workspace A and Bob belongs only to Workspace B. Each workspace contains a disposable document. The rule is that a member may read documents only from their own workspace; neither account is an administrator.
First confirm that Alice can read the Workspace A document and Bob can read the Workspace B document. Then, using Bob’s own session, request the known identifier of Alice’s synthetic document through the document-detail operation. A failing implementation might return the Workspace A document because its lookup checks the document ID but does not enforce workspace membership. Do not search for unknown record identifiers or use customer records.
Enforce the actor-to-workspace relationship in trusted application code or the appropriate database policy before returning the record. After deployment, repeat the denied request and both legitimate reads. Record the deployment version, sanitized evidence and outcome separately. A particular HTTP status code alone does not prove the boundary: some applications deliberately use 404 rather than 403, and a denial must not contain private data.
- Alice reads the Workspace A document: Allowed, evidence shows intended record returned.
- Bob reads the Workspace B document: Allowed, legitimate access works.
- Bob requests the Workspace A document: Denied without exposing document data, sanitized response retained.
- Unauthenticated client requests either document: Denied, no private content exposed.
- Bob retries after Workspace B membership is removed: Denied, removed access invalid.
Enforce the rule in a trusted layer
Client-side visibility is a usability feature, not an access boundary. A hidden button, an unlinked page, or an unpredictable identifier cannot substitute for a server-side check. The OWASP Authorization Cheat Sheet recommends enforcing "deny by default" explicitly and relying on shared logic to validate every request globally.
Database row-level security can provide another boundary when configured for the runtime role. Review policy coverage for reads, writes, background workers, and privileged functions. Avoid assuming that framework defaults are sufficient for authorization; verify that they map securely to your product's requirements.
Keep regression evidence and legitimate access working
For a confirmed issue, record the expected permission, test identities, synthetic record, affected route, observed result, and relevant deployment version. Redact session tokens and personal information. Explain the data or operation exposed rather than assigning severity from the route name alone.
After remediation, retest the forbidden path and an allowed path. Add a focused regression check at the layer that owns the permission rule. Passing this review covers the cases tested; it is not a guarantee that every access-control flaw has been eliminated.
Sources and Acknowledgments
OWASP Authorization Cheat Sheet. Retrieved 2026-11-12. https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.
Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.
Prepared with AI assistance and published by WarHound AI. Check the references and evidence limits in each article.
The WarHoundAI journalQuestions or a factual correction? Get in touch with the article URL and supporting evidence.