Authentication and security

Signed in does not mean allowed

A valid session proves identity. It does not prove ownership of a project, access to an organisation, or permission to perform an administrative action.

Check permissions at the server operation that touches protected data.

Put security close to the data

Server Actions, Route Handlers, and server-side data functions should enforce the permissions they rely on. Layout checks and hidden controls can improve UX, but they are not enough by themselves.

Keeping these checks close to data access also makes it harder for a future entry point to accidentally bypass them.

NEXT_PUBLIC_ means public

Server-only environment variables can hold secrets. Variables intentionally exposed with NEXT_PUBLIC_ can enter browser bundles and must be treated as public information.

The prefix does not make a secret safe. It does the opposite: it tells the build that the value is allowed on the client.

DATABASE_URL=...             # server only
AUTH_SECRET=...              # server only
NEXT_PUBLIC_ANALYTICS_ID=... # intentionally public

The boring controls still matter

• Validate untrusted input on the server.
• Check resource ownership and roles.
• Use secure, HTTP-only, same-site cookies where appropriate for session identifiers.
• Protect state-changing operations from cross-site abuse.
• Rate-limit expensive or sensitive public endpoints.
• Return only the fields the client actually needs.
• Keep dependencies and the framework patched.