beginnerintermediateadvanced

Django · Section 39

Sessions and Cookies

Level: intermediate
Read: 20 min
Concepts: 2

SessionMiddleware is what makes request.session exist at all, delegating actual storage to SESSION_ENGINE — the database backend (default) is durable, cache trades durability for speed, cached_db combines both, and signed_cookies stores the session data in the cookie itself, cryptographically signed but explicitly NOT encrypted, so nothing sensitive belongs there. SESSION_COOKIE_AGE sets a fixed lifetime from creation, not an idle timeout, unless paired with SESSION_SAVE_EVERY_REQUEST; session.flush() is the real invalidation call, rotating the session key — the same mechanism login()/logout() use to defend against session fixation. Secure (HTTPS-only), HttpOnly (blocks JavaScript access, mitigating XSS-driven theft), and SameSite (restricts cross-site cookie attachment, a partial CSRF mitigation) each close a genuinely different gap. The CSRF relationship: a session cookie is attached automatically by the browser regardless of which site asked for the request, which is exactly what CSRF exploits — the CSRF token is separate proof the request actually originated from the app's own page, and SameSite alone was never meant to fully replace it.

This section

Django Sessions - Introduction to Session Data and CookiesBugBytes

What is true here

SessionMiddleware makes request.session exist; SESSION_ENGINE (db/cache/cached_db/signed_cookies) decides where the data actually lives.
signed_cookies stores session data in the cookie itself — cryptographically signed, but NOT encrypted, so nothing sensitive belongs there.
SESSION_COOKIE_AGE is a fixed lifetime from creation, not an idle timeout, unless SESSION_SAVE_EVERY_REQUEST is also set.
session.flush() rotates the session key — the actual defense against session fixation, used internally by login()/logout().
Secure/HttpOnly/SameSite each stop a different attack; SameSite is a partial CSRF mitigation, not a substitute for the CSRF token.

What you will be able to do

Choose the right SESSION_ENGINE for a project's durability/speed/infrastructure trade-off
Configure production-appropriate cookie security flags without breaking legitimate cross-site navigation
Explain why login() defends against session fixation, and invalidate a session correctly with flush()
Articulate how session cookies and CSRF tokens are separate, complementary mechanisms

Session middleware and storage backends

How request.session gets populated, where the data lives, and expiration vs invalidation.

Session middleware and the storage backends

coreintermediate

SessionMiddleware is what makes request.session exist at all — it reads a session id from a cookie, loads that session's data via SESSION_ENGINE, and saves it back at the end of the request if it changed. The database backend (default) stores session data in the django_session table — durable, but a query per session load. The cache backend stores it in whatever CACHES backend is configured (fast, but ephemeral if that cache is ever cleared) — "cached_db" combines both, writing to the database but reading from cache first. The signed_cookies backend stores the session data itself in the cookie (cryptographically signed, not encrypted) — no server-side storage at all, but capped by the browser's ~4KB cookie limit and, being signed rather than encrypted, still readable (not just tamperable) by the client. SESSION_COOKIE_AGE sets expiration; session.flush() invalidates a session outright.

Think of it as

A session needs somewhere to actually live between requests, and Django deliberately makes that a swappable ENGINE (SESSION_ENGINE) rather than one fixed mechanism, because the right trade-off differs by project: the database backend is the safe default (durable, no extra infrastructure), the cache backend trades durability for speed (fine if losing sessions on a cache flush just means re-login, not data loss), and signed_cookies removes server-side storage entirely by putting the data itself in the cookie — which only works because Django signs it (SECRET_KEY-based, tamper-evident) though it is explicitly NOT encrypted, so anything sensitive stored in a signed-cookie session is still readable by the client, just not forgeable. Expiration and invalidation are two different concerns: SESSION_COOKIE_AGE (and SESSION_EXPIRE_AT_BROWSER_CLOSE) control how long a session naturally lives, while session.flush() is an explicit "kill this session right now" — the operation login()/logout() actually perform under the hood, which is why logging out invalidates a session rather than merely expiring it early.

python

request.session["key"] = value
request.session.get("key")
request.session.flush()

What we're doing: Switch a high-traffic site from the default database backend to cached_db, and explicitly flush a session on a security-sensitive action.

settings.py + views.pypython

# settings.py
SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"

# views.py
def force_password_reset(request):
    request.user.set_password(new_password)
    request.session.flush()   # invalidate this session; user must log in again
    return redirect("login")

2: cached_db still writes through to the database on every save — switching engines is a read-path optimization, not a way to skip durability.
7: flush() is stronger than just clearing session data — it also rotates the session key, the same mechanism login()/logout() use to prevent fixation.

Why this works: A password change is exactly the kind of event that should invalidate any existing session outright rather than let it continue — flush() (not just del request.session["..."]) is the correct call because it also generates a new session key, closing off any pre-existing session id an attacker might have already obtained.

Choosing signed_cookies for a session storing anything sensitive, assuming "signed" means "encrypted"

Wrong

python

# SESSION_ENGINE = "django.contrib.sessions.backends.signed_cookies"
request.session["internal_role"] = "senior_underwriter"   # readable by the client!

Better

python

# SESSION_ENGINE left at the default "db" (or cached_db)
request.session["internal_role"] = "senior_underwriter"   # stored server-side, opaque to the client

What you see: Nothing appears broken functionally — the signature check does prevent a TAMPERED cookie from being accepted — but any sensitive value stored in the session is directly visible to the client (and anyone with access to their browser/network capture) simply by base64-decoding the cookie, since signing proves authenticity, not secrecy.

Why: Django's own documentation is explicit that signed_cookies sessions are signed, not encrypted — the cryptographic signature stops a client from CHANGING the value undetected, but does nothing to stop them from READING it. Storing anything a user shouldn't be able to see (roles, internal flags, other users' data) in a signed-cookie session defeats the purpose even though tampering is still blocked.

Where session data actually lives

db / cache / cached_db

+Server-side storage
+db: durable, one query per load
+cache: fast, ephemeral; cached_db: both

signed_cookies

−No server storage — data lives in the cookie
−Signed (tamper-evident), NOT encrypted
−Capped at ~4KB — never store sensitive data

Session storage backends

Session storage backends
SESSION_ENGINE	Stores data	Trade-off
db (default)	django_session table	durable, one query per session load unless cached elsewhere
cache	configured CACHES backend	fast, but data is lost if the cache is cleared/evicted
cached_db	both — cache-first read, database write-through	cache speed + database durability, needs both configured
signed_cookies	the cookie itself	no server storage at all, but ~4KB limit and NOT encrypted (signed only)

Together

python

# settings.py
SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"
SESSION_COOKIE_AGE = 1209600  # 2 weeks

Remember: SessionMiddleware makes request.session exist by reading/writing a cookie and delegating to SESSION_ENGINE (db by default; cache trades durability for speed; cached_db combines both; signed_cookies needs no server storage but is signed, NOT encrypted — never store anything sensitive there). SESSION_COOKIE_AGE alone is a fixed lifetime, not an idle timeout, unless paired with SESSION_SAVE_EVERY_REQUEST. session.flush() is the real invalidation call — it also rotates the session key.

Secure/HttpOnly/SameSite, why login() defends against fixation, and how CSRF relates to the session cookie.

coreintermediate

SESSION_COOKIE_SECURE (send the cookie over HTTPS only) and SESSION_COOKIE_HTTPONLY (block JavaScript from reading it, mitigating XSS-driven theft) are two independent hardening flags — both should be True in production. SESSION_COOKIE_SAMESITE (default "Lax") restricts when the browser attaches the cookie to a cross-site request, which is Django's cookie-level defense against CSRF, distinct from the CSRF middleware's own token check. Session fixation is an attack where an attacker gets a victim to use a session id the attacker already knows, then waits for the victim to log in under it — Django's login()/logout() defend against this automatically by rotating the session key (flush()) rather than reusing whatever key existed pre-login. The CSRF relationship: session cookies and the CSRF token are separate mechanisms working together — the session proves who you are across requests, the CSRF token proves a specific unsafe request actually originated from your own page, not a third-party site riding on your already-authenticated session.

Think of it as

These settings exist because a cookie, once issued, is genuinely vulnerable to several DIFFERENT attacks, and each flag closes one specific gap rather than being redundant with the others: Secure stops the cookie ever crossing an unencrypted connection (a network-level interception risk); HttpOnly stops JavaScript from reading it (an XSS-exfiltration risk, since even a successful script injection can't steal a cookie it can't see); SameSite restricts which cross-site requests even ATTACH the cookie (a CSRF-adjacent risk, since a forged request from another origin, under SameSite=Lax/Strict, often won't carry the session cookie at all). Session fixation is a distinct attack shape from cookie theft — the attacker never needs to see the victim's cookie, only to plant a session ID the victim will end up authenticated under (e.g. via a URL parameter on a site that accepts it) — which is exactly why login() rotating the session key on success, not just adding auth data to whatever session already existed, is the actual fix, not a cookie flag. CSRF and sessions relate because CSRF specifically exploits the fact that a browser automatically attaches cookies (including the session cookie) to any request to a site, even one the browser was tricked into sending from a different page — the CSRF token is proof of same-origin INTENT that the cookie alone can never provide, since the cookie is sent automatically regardless of who asked for the request.

python

SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"  # or "Strict"

What we're doing: Harden session cookie settings for production, and explain why login() alone already handles fixation.

settings.pypython

if not DEBUG:
    SESSION_COOKIE_SECURE = True
    SESSION_COOKIE_HTTPONLY = True
    SESSION_COOKIE_SAMESITE = "Lax"
    CSRF_COOKIE_SECURE = True

2: Guarded by `if not DEBUG` — Secure cookies require HTTPS, which a local dev server usually doesn't have; forcing this in DEBUG mode would break local login entirely.

Why this works: These four settings each close a different, specific gap (network interception, XSS cookie theft, cross-site cookie attachment) — none is redundant with another, so production hardening means setting all of them, not picking just one.

Setting SESSION_COOKIE_SAMESITE = "Strict" without checking cross-site-navigation flows still need to work

Wrong

python

SESSION_COOKIE_SAMESITE = "Strict"
# a user clicking a link to the site FROM AN EXTERNAL EMAIL or another site
# arrives logged out even though they have a valid session — Strict withholds
# the cookie on that top-level cross-site navigation too

Better

python

SESSION_COOKIE_SAMESITE = "Lax"   # the Django default — still attaches on
# top-level navigation (clicking a link), just not on cross-site subrequests

What you see: Users following a link from an external email, a search result, or another site land on the app apparently logged out, even though their session is still valid — a support ticket that reads like a session bug but is actually a cookie policy choice.

Why: "Strict" withholds the cookie on EVERY cross-site request, including a simple top-level navigation like clicking a link — "Lax" (Django's own default) is the deliberate middle ground: it still blocks the cross-site subrequests CSRF actually exploits (forged form posts, fetch calls from another origin) while still attaching the cookie for an ordinary top-level link click, which is why Lax, not Strict, is what most sites actually want.

Three independent flags, three different gaps

Secure

never sent over plain HTTP

HttpOnly

JavaScript can't read it — mitigates XSS theft

SameSite

restricts cross-site attachment — partial CSRF mitigation

Cookie hardening flags and what each actually stops

Cookie hardening flags and what each actually stops
Setting	Stops
SESSION_COOKIE_SECURE	the cookie ever being sent over plain HTTP
SESSION_COOKIE_HTTPONLY	JavaScript (including injected XSS) from reading the cookie
SESSION_COOKIE_SAMESITE	the cookie being attached to most cross-site requests
Session key rotation on login()	a pre-login session id (session fixation) from ever becoming authenticated

Together

python

# settings.py — production hardening
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
CSRF_COOKIE_SECURE = True

Remember: SESSION_COOKIE_SECURE (HTTPS only), HTTPONLY (blocks JS access, mitigates XSS theft), and SAMESITE (restricts cross-site attachment, a partial CSRF mitigation) each close a different, specific gap — none is redundant with another. Session fixation is defended by login() rotating the session key via flush(), not a cookie flag. The CSRF token and the session cookie are separate mechanisms: SameSite alone is not a full CSRF defense, and shouldn't be used to justify @csrf_exempt.

Session middleware and storage backends

Cookie security, session fixation, and CSRF