A signed cookie shows tampering but is readable by the user. An encrypted, authenticated cookie hides the contents as well. A server-side session stores the data on the server and puts only a random ID in the cookie. Choose by what the data contains and how fast you need to revoke it.
What signing gives you
Django's signing documentation describes the model: you can pass data through an untrusted channel and detect any modification, and a changed value raises a BadSignature error. Its examples also show the payload is only encoded, so anyone who sees the value can read it. Signing alone is wrong for anything private.
The secret key is what protects the scheme. The docs say an attacker who knows it could generate their own signed values. A salt works as a namespace so a value signed for one purpose is not accepted for another, and it does not need to be secret. Use a different salt for each use.
Freshness and rotation
A signature alone does not say how old a value is. Django's timestamp signer lets you set a maximum age and rejects older values; without it, a valid old signature still passes. Django also supports fallback keys that only validate existing signatures and never sign new data, which makes key rotation smooth.
Comparing the three designs
- Signed cookie: simple, stateless, readable. Good for non-sensitive flags such as a preference with integrity.
- Encrypted and authenticated cookie: stateless and private. Size limits apply, and revoking one session early is hard without extra state.
- Server-side session: the cookie holds a random ID, and the data lives in a store. Easy to revoke and no data sits at the client. It needs shared storage across servers.
Choosing
- Does it hold anything sensitive? If yes, encrypt it or keep it on the server.
- Do you need instant logout or revocation? Prefer server sessions or a revocation list.
- Is horizontal scale easy with a shared store? If yes, server sessions are a strong default for logins.
- Would one leaked secret key let someone forge any user? With stateless cookies, yes, so plan key rotation.
Cookie attributes still matter
Set Secure, HttpOnly and a suitable SameSite value on session cookies. Those attributes are separate from signing and work alongside it.
Quick check
Can users edit a signed cookie?
They can edit the text, but the signature will no longer match, so a correct check rejects it.
Should I put roles inside a signed cookie?
You can, but re-check permissions server-side for sensitive actions, because roles can change after the cookie is issued.
Sources
Last reviewed: 19 October 2026.
