Read what your authorization tests actually assert. If each one acquires a token, calls an endpoint and expects 200, with a partner case expecting 401 when the token is absent, then the suite covers authentication and has authorization in its file names.
\n\nNothing in that shape can see the two failures that matter most. An invoice PDF fetched by any logged-in account that guesses the ID, and a customer setting creditLimit on their own account by including it in an ordinary profile update, both arrive carrying a valid token belonging to a real user. Every assertion in that suite calls them authorized, because every assertion only ever asked who was calling.
OWASP's 2023 edition splits these into separate categories because they fail independently, and the boundaries are worth stating precisely rather than approximately.
\n\nWho is calling is authentication. A missing or expired token is the only thing a no-token test covers.
\n\nWhich object is object-level authorization, API1:2023. The category text is explicit that the caller is supposed to be able to reach the endpoint: \"it's by design that the user will have access to the vulnerable API endpoint/function. The violation happens at the object level, by manipulating the ID.\" It also warns that comparing the session user ID against the ID in the request \"isn't a sufficient solution\", because it only covers the case where the object belongs directly to the caller.
\n\nWhich function is API5:2023, and OWASP draws the line for you: if an attacker reaches an endpoint or function they should not have access to at all, that is broken function-level authorization rather than object-level. The category names two probes worth stealing directly — whether a user can perform a sensitive action by changing only the HTTP method, and whether an administrative function can be reached by guessing a URL. It also warns against assuming an endpoint is administrative from its path, since admin operations frequently live under the same prefix as ordinary ones.
\n\nWhich property is API3:2023, which merged two categories that used to be separate: excessive data exposure on the read side, where a response carries properties this caller should not see, and mass assignment on the write side, where a caller sets a property they should not control. One grid cell per operation cannot hold both, because they need different evidence.
\n\nBefore generating anything, read the security declarations in the OpenAPI description. Three of its rules are routinely misread, and each produces a real gap.
The first is that the two ways of writing \"optional\" mean different things. An empty Security Requirement Object, {}, indicates anonymous access is supported, so security: [{}, {oauth: [...]}] means authenticated or anonymous. An empty array on an operation removes the top-level declaration entirely, so security: [] means no scheme applies at all. One is a deliberate public endpoint; the other is usually a leftover from local development.
The second is that nesting decides AND against OR. Multiple schemes inside one Security Requirement Object must all be satisfied. Multiple Security Requirement Objects in the array are alternatives, and only one needs to be satisfied to authorize the request.
\n\n/v1/accounts/{id}/credit-limit:\n patch:\n security:\n # OR: either entry alone authorizes the request. The API key path\n # reaches this operation without the admin scope ever being checked.\n - oauth2: [accounts:admin]\n - internalApiKey: []\n/v1/invoices/{id}:\n get:\n security: [] # removes the root declaration: no scheme at all\n/v1/status:\n get:\n security:\n - {} # anonymous access is supported, alongside the root\n The third is that role names carry no weight outside OAuth. For an oauth2 or openIdConnect scheme the array holds required scope names; for other scheme types the specification says the array may contain role names \"which are required for the execution, but are not otherwise defined or exchanged in-band\". A description showing internalApiKey: [admin] documents an intention, and nothing in the request conveys it. Every operation of that shape needs a test, because the description will not fail a validator.
One caveat on using the description as the inventory: OAS permits security filtering, where a served description omits paths or operations the reader cannot access. The copy you fetched may be smaller than the API. Treat it as a lower bound and reconcile it against the router, which is the same reason OWASP lists inventory management as its own category.
\n\nThe grid's key is the four questions plus state, and the default matters more than the contents: if unlisted cells are treated as untested, the grid grows quietly stale. Make an unlisted cell mean deny, so adding an operation immediately produces failing allow-tests that somebody has to justify.
\n\n// contracts/authorization-grid.ts\ntype Verdict = 'allow' | 'deny';\n\n// Actors are relationships to the object, not job titles. \"Owner\" and\n// \"same-tenant colleague\" differ in the code path; \"manager\" and \"lead\"\n// usually do not.\nexport const actors = ['owner', 'sameTenantOther', 'otherTenant', 'tenantAdmin', 'anonymous'] as const;\n\n// Only the cells that are ALLOWED are listed. Everything else denies.\nexport const allowed: Record<string, readonly (typeof actors)[number][]> = {\n 'GET /v1/invoices/{id}': ['owner', 'tenantAdmin'],\n 'PATCH /v1/invoices/{id}': ['owner'],\n 'POST /v1/invoices/{id}/approve': ['tenantAdmin'],\n 'DELETE /v1/invoices/{id}': ['tenantAdmin'],\n 'GET /v1/accounts/{id}/credit-limit': ['tenantAdmin'],\n 'PATCH /v1/accounts/{id}/credit-limit': ['tenantAdmin'],\n};\n\nexport const verdictFor = (cell: string, actor: string): Verdict =>\n (allowed[cell] ?? []).includes(actor as never) ? 'allow' : 'deny';Two details keep this from exploding. Actors are defined by their relationship to the object rather than by role name, because that is what the handler branches on — an API with nine job titles usually has four distinct code paths. And one representative object per relationship is enough; a second invoice owned by the same user exercises no new branch.
\n\nNote what the DELETE row buys you. It is the method-swap probe OWASP describes, and it is the row people leave out because no client sends it. An endpoint whose GET is correctly guarded and whose DELETE was never wired to a check will pass every test written from the client's behaviour.
Asserting a status code is not enough for a deny cell, because the status itself can leak. RFC 9110 permits an origin server that wants to hide a forbidden resource to answer 404 instead of 403, which means 403 on a real ID and 404 on a fabricated one together confirm which IDs exist. The assertion that holds is equality between the two responses.
\n\nThree codes with three different meanings are in play, and one of them carries a requirement almost every API violates. A 401 says the request lacks valid credentials for the target resource, and RFC 9110 states that a server generating 401 MUST send a WWW-Authenticate header containing at least one challenge. A 403 says the server understood and refuses. A 404 says no representation was found, or the server is unwilling to disclose that one exists.
import { test, expect, type APIRequestContext } from '@playwright/test';\nimport { actors, verdictFor } from '../contracts/authorization-grid';\n\nasync function assertDenied(\n ctx: APIRequestContext,\n send: (c: APIRequestContext) => Promise<import('@playwright/test').APIResponse>,\n control: (c: APIRequestContext) => Promise<import('@playwright/test').APIResponse>,\n) {\n const [actual, fabricated] = await Promise.all([send(ctx), control(ctx)]);\n\n expect(actual.status()).toBe(fabricated.status());\n // Identical bodies: a message naming the owner, the tenant, or the reason\n // discloses the object's existence even when both statuses match.\n expect(await actual.text()).toBe(await fabricated.text());\n\n if (actual.status() === 401) {\n // RFC 9110 15.5.2 makes this mandatory, and it is usually missing.\n expect(actual.headers()['www-authenticate']).toBeDefined();\n }\n expect([401, 403, 404]).toContain(actual.status());\n}Response timing deserves a mention and not a test. A lookup that returns quickly for an unknown ID and slowly for a forbidden one is a real disclosure channel, and it is also the assertion most likely to flake in CI. Measure it during a security review with enough samples to mean something, and keep it out of the suite that gates merges.
\n\nThe read side is the easy half: fetch the object as each actor and assert that restricted properties are absent rather than empty. A null in the response tells the caller the field exists and that they cannot see it, which is a smaller leak than the value but a leak all the same.
The write side is where suites go wrong, because the obvious assertion is invalid. Sending {\"creditLimit\": 500000} as an ordinary user and asserting the response does not echo creditLimit proves nothing: the field is filtered out of that user's view by the read rule, whether or not the write landed. The value has to be read back by an identity permitted to see it.
test('a customer cannot raise their own credit limit', async ({ playwright }) => {\n const customer = await playwright.request.newContext({ extraHTTPHeaders: tokenFor('owner') });\n const admin = await playwright.request.newContext({ extraHTTPHeaders: tokenFor('tenantAdmin') });\n\n const before = await (await admin.get(`/v1/accounts/${accountId}/credit-limit`)).json();\n\n const attempt = await customer.patch(`/v1/accounts/${accountId}`, {\n data: { displayName: 'Ravi K', creditLimit: 500_000 },\n });\n\n // Either answer can be correct: reject the request, or accept it and ignore\n // the field. What is never correct is the value changing.\n expect([200, 403, 422]).toContain(attempt.status());\n\n const after = await (await admin.get(`/v1/accounts/${accountId}/credit-limit`)).json();\n expect(after.creditLimit).toBe(before.creditLimit);\n\n // The legitimate part of the same request must still have applied, or the\n // API is rejecting the whole update and the test proves the wrong thing.\n const profile = await (await customer.get(`/v1/accounts/${accountId}`)).json();\n expect(profile.displayName).toBe('Ravi K');\n});The last assertion is the one that catches a lazy fix. Rejecting any request containing an unrecognised property makes this test pass and breaks every client that sends a field the server does not care about, so verify that the permitted half of the update still applied.
\n\nSome cells are not constant. An invoice owner may edit a draft and may not edit the same invoice after approval; a support agent may refund an order only while it is unshipped. When that is true, the pair (actor, operation) is not a cell — (actor, operation, state) is, and a grid keyed on the pair will record whichever verdict the fixture happened to produce.
\n\nThe economical way to handle it is to expand only the operations where a stakeholder can name a state that flips the answer, and to write both halves as one test so the contrast is visible:
\n\ntest('the owner may edit a draft invoice and not an approved one', async ({ request }) => {\n const draft = await seedInvoice(request, { owner: 'owner', state: 'DRAFT' });\n const approved = await seedInvoice(request, { owner: 'owner', state: 'APPROVED' });\n\n expect((await request.patch(`/v1/invoices/${draft.id}`, { data: { note: 'x' } })).status()).toBe(200);\n expect((await request.patch(`/v1/invoices/${approved.id}`, { data: { note: 'x' } })).status()).toBe(403);\n});Watch for the code that answers 403 here for the wrong reason. An implementation that denies edits to approved invoices by checking the state and forgetting ownership will pass this test and still let a different tenant edit a draft, which is why the state expansion sits on top of the ownership grid rather than replacing it.
\n\nFive actors across forty operations is two hundred cells, most of them denials, and running all of them on every pull request is not free. The reductions worth making are the ones that drop cells the code cannot distinguish: collapse roles that share a code path into one actor, use a single representative object per relationship, and run the full grid nightly while pull requests run only the allow cells plus the denials on operations that changed.
\n\nThe reduction not worth making is dropping deny cells because they are boring. They are the entire point; the allow cells mostly re-test the happy path other suites already cover. If pressure comes to shrink the suite, shrink the allow side.
\n\nThe honest cost is fixture weight. Every actor needs a real identity with a real relationship to a real object, and that setup is more fragile than the assertions it supports. Seeding through the API as a privileged actor keeps it truthful at the price of slower tests; seeding directly into the database is faster and will eventually drift from what the application would have created.
\n\nA shared fixture token with broad permissions makes setup easy and makes every deny cell unreachable. The symptom is a suite where no test ever expects a 403. Grep for the expected statuses across the directory: if 403 and 404 do not appear, the grid has one actor no matter how many the file lists.
\n\nAn edge policy blocking the route produces a correct-looking 403 while the handler behind it has no check at all. The discriminating test is to issue the same request inside the network boundary, or against a preview environment where that policy is absent, and see whether the verdict survives. It usually does not, and the finding is worth more than the rest of the grid combined, because any path that bypasses the edge — an internal caller, a misrouted header, a new ingress — bypasses authorization entirely.
\n\nFixtures that create every object with the same seeding call often attach them all to the same tenant, so the \"other tenant\" actor is reading its own data and getting a legitimate 200. Assert the setup as well as the outcome: before the deny case runs, confirm as an administrator that the object's owner is not the actor under test. A deny test whose fixture is wrong reports the safest possible result.
\n\nPick one per resource type and be consistent, because consistency is what removes the signal. 404 everywhere hides existence and costs debuggability; 403 everywhere is clearer and tells a caller that an ID they guessed is real. The middle option leaks the most: 403 for objects that exist and 404 for those that do not turns any endpoint into an existence oracle. Whichever you choose, the test asserts equality with the fabricated-ID response rather than a literal code, so the suite survives the decision changing.
\n\nIt covers the function question and none of the others. A scope says this token may call this operation; it says nothing about which invoice. It is also worth confirming the scope is enforced rather than declared — the description's scope list is documentation, and for non-OAuth schemes the specification is explicit that role names in that array are not exchanged in the request at all. Test it by calling the operation with a token deliberately issued without the scope.
\n\nThe four questions do; the grid key changes. Operations become root fields and mutations, and the property question gets sharper rather than softer, because the client chooses which fields to request. OWASP's own API3:2023 example is a GraphQL mutation that returns properties of a reported user the caller should not see. Key the grid on (actor, field path) for reads and on (actor, mutation, argument) for writes, and remember that a nested field may be resolved through a path that skips the parent's check.
\n\nIt expands the shape well and must not decide any cell. Given the actor list and the operation list it will produce the full cross product and reasonable test scaffolding, which is genuinely useful because the cross product is tedious and easy to leave incomplete. The verdict in each cell has to come from the written policy or the person who owns it. A model asked to guess will fill cells with what is conventional, and conventional is exactly how the customer got a credit limit field.
\n\nWWW-Authenticate challenge, the meaning of 403, and the permission to answer 404 instead of 403 to hide a resource's existence{} meaning anonymous access, and role names in non-OAuth schemes not being exchanged in-band; the Operation Object (§4.8.10.1) for security: [] removing the top-level declaration; and Security Filtering (§4.10) for descriptions that legitimately omit what the reader cannot accessnewContext with per-identity extraHTTPHeaders, which is how each actor in the grid gets its own clientOpen the OpenAPI description and search it for security: [] and for security arrays with more than one entry. The first list is operations with no scheme at all; the second is operations where the weakest alternative is the one that decides. Both are testable today and neither needs a grid.
Then take the single most sensitive object in your API and write four tests for it: the same-tenant colleague reading it, the other tenant reading it, the owner calling its administrative action, and the owner setting one property they should not control. Assert the denials by equality against a fabricated ID, and read the property back as an administrator. Record three things from that run: the actor list with the code path each one exercises, the response pair behind every denial, and the identity that performed each read-back. If a deny cell was proved by a response the actor under test could have produced for a legitimate reason, it is not proved.
\n"}