A signed cookie is not object authorization

Signed cookies are great for integrity: the browser cannot silently rewrite a payload you sealed with a server secret. That still does not decide which objects the user may touch.

Teams often stuff a user id, a role, or even a tenant id into a signed cookie and then treat “signature valid” as “request authorized.” The cookie only proves the blob was minted by you. It does not prove the caller may read invoice #4821, mutate another user’s project, or act across tenants.

What to do instead:

1. Authenticate the session (cookie, token, whatever) to learn who is calling.
2. Authorize the action + object on the server for that principal on every sensitive request — including ones that look “read-only.”
3. Never trust client-supplied ids just because they ride inside a signed envelope. Re-load the resource and check ownership/relationship/policy against the authenticated user.
4. Keep cookies short-lived and rotatable; signature alone is not revocation or least privilege.

Quick check: change the object id in a still-valid signed cookie request. If the server returns another user’s data because the signature verified, you never had authorization — only a sealed identity claim.

Integrity answers “was this tampered with?” Authorization answers “may this user do this to this object?”