Security consideration: automatically set overrideAccess to false when a user is passed to local api

[tylkomat]

According to the documentation setting a user allows setting overrideAccess to false. I don't see a use case where a user would be set, but overrideAccess is kept to true. In my case I forgot to set it to false and my access control was bypassed, as expected, but not as intended. In my multi tenant application data was basically visible to all tenants because of that.

I would even argue to make overrideAccess: false by default. It is easier to spot when something does not work, compared to if "too much" is working. This would be a breaking change, which could be mitigated by an update script which updates all usages.

From a security point of view it is better to start with most security and leave it to the user to actively reduce security, compared to leave it to the user to harden security.

[lol768]

As someone new to Payload, it looks like a really nice tool - .... but, it seems completely nuts to me that the default here is true.

By default, Local API operations bypass ALL access control, even when passing a user.

// ✅ SECURE: Actually enforces the user's permissions
await payload.find({
  collection: 'posts',
  user: someUser,
  overrideAccess: false, // REQUIRED for access control
})

// ✅ Administrative operation (intentional bypass)
await payload.find({
  collection: 'posts',
  // No user, overrideAccess defaults to true
})

Turning off access control should surely be an opt-in operation?

It's such a sharp edge that the templates include warnings for LLMs to keep in mind. Shouldn't this have set alarm bells ringing that the design lent itself to shooting yourself in the foot?