Berechtigungen testen

Authorization Testing

Every request is checked on the server, for the specific record, every time. Prove it with tests that try what must fail.

Build the access matrix

• List the roles (signed out, ordinary user, owner, member of another tenant, support, admin) and the actions per resource (list, read, create, update, delete, export, admin actions).
• Mark each cell allowed or forbidden from the requirements, not from what the code does. Unclear cells are questions for the product owner, not guesses.
• Test with at least two users per role and two tenants, each with its own seeded data.

What to try

• Horizontal (IDOR): as user A, call every changed endpoint with B's ids in the path, query, body and headers, nested ids (a comment id inside A's post), bulk endpoints and exports. Expect 403 or 404, and no change to B's data.
• Predictable ids make enumeration easy; ids that are hard to guess still need the check.
• Vertical: as an ordinary user, call admin and support endpoints directly; try to change your own role, plan, tenant or owner through any writable field (mass assignment); call the API behind hidden UI actions.
• Signed out and expired: every protected endpoint without a session, with an expired or revoked token, after logout, and after a password or role change.
• Variants: other HTTP methods on the same path, older API versions, GraphQL fields and batch requests.
• Indirect paths: file downloads and signed URLs, websocket channels, background jobs, search and autocomplete, reports, emails and notifications that include other users' data.
• State: actions on archived, deleted or locked records, and workflow steps limited to certain roles or states.

Tenant isolation

• Every query, cache key, file path, search index, queue message and export carries the tenant scope; check each kind the change touches.
• Create look-alike records in two tenants and confirm that lists, counts, search, totals and reports never mix them.
• Cached responses vary by user and tenant; a shared cache key leaks data.

Data exposure

• Responses return an allowlist of fields: no password hashes, tokens, internal flags or other users' personal data. Check list views and error responses too.
• Errors do not reveal whether another user's record exists; answer missing and forbidden the same way where that matters.
• Logs, analytics and error reports carry no tokens, secrets or unneeded personal data.

Enforcement

• The check lives in server code for every endpoint and action, close to the data access. Hiding a button is not authorization.
• Deny by default: an endpoint without an explicit rule is forbidden. Look for routes that skip the shared middleware or policy.
• Login, password reset and other sensitive endpoints are rate limited.

Writing the tests

• Automate the matrix for the changed resources: one test per forbidden cell, asserting both the status and that nothing changed.
• Keep tests for the allowed cells too, so over-restriction shows up.
• Report each finding with the role, the request, the response and the data reached. Reading or changing another user's or tenant's data is critical.

Before you finish

• Access matrix written for the changed resources.
• Cross-user, cross-tenant, role and signed-out cases tested on every changed endpoint.
• Indirect paths (files, jobs, search, exports) checked.
• Responses, errors and logs expose nothing beyond need.