Payload CMS Penetration Testing

By default, Payload’s Local API skips every access control check, so a call to payload.find or payload.update from your own server code runs with the same reach as an administrator unless overrideAccess is explicitly set to false.

Why Payload access control is code you write, not a role you tick

Payload ships no default roles or example permission matrix. Every collection’s create, read, update and delete function is a plain function your team writes, and Payload’s own access control documentation confirms that read, update and delete can each return a Query constraint that narrows the result to matching documents, while create can only return a boolean because no document exists yet to filter against. Left undefined, an operation falls back to Payload’s own default, a single check for whether a user is present on the request, so the absence of a rule quietly becomes ‘anyone logged in, on everything’. We test what each function actually returns against what the collection is meant to expose, not what a role name implies.

A second, independent layer sits on individual fields: field-level create, read and update functions run in addition to the collection’s own rules, but they can only return a boolean, never a Query constraint, and a field denied on update is silently dropped rather than throwing an error, so a blocked write can look like it succeeded. Authentication adds a third dimension. Auth-enabled collections issue an HTTP-only cookie and a JWT on login, with revocable sessions on by default, and a collection can also carry a non-expiring API key per user, sent as an Authorization header naming the collection slug, checked against the same access control as a password. We test all three layers, collection, field and authentication, for where a permission was written once and assumed to cover the rest.

Payload’s most consequential default sits outside the Admin Panel entirely. Its Local API skips access control by default, so any payload.find, payload.create or other call runs with overrideAccess set to true unless the code explicitly sets it to false and supplies a user, and because Payload runs fully inside your own Next.js application, this is the exact API your React Server Components, custom route handlers and seed scripts call directly. Custom endpoints carry the same responsibility in the other direction: Payload states plainly that they are not authenticated by default, and a plain Next.js Route Handler dropped into the app directory sits outside Payload’s endpoint config altogether. We test every server-side call and every custom route for whether it checks who is asking, rather than assuming the framework already did.