Using Flask Sessions

Flask exposes a session dict-like object:

python

from flask import session

The client can read a Flask session — it just cannot change it

Verified with Flask 3.1.3. A session containing {"user_id": 7, "role": "admin"} becomes this cookie:

text

eyJ1c2VyX2lkIjo3LCJyb2xlIjoiYWRtaW4ifQ.ana4rA.BKDzGipqjYwKdqU6qEo_JnyM0TQ

Base64-decoding the first segment gives back, exactly:

text

{"user_id":7,"role":"admin"}

Signed is not encrypted. Anyone holding the cookie can read every value in it. Editing it and sending it back fails — the load raises BadTimeSignature — but that only protects integrity, not secrecy.

So never put anything in session that the user should not see: no API keys, no internal flags you rely on being hidden, no other person’s data. Store an id and look the rest up.

Requirements

Sessions require:

• app.config["SECRET_KEY"]

Setting and reading values

python

from flask import Flask, session
 
app = Flask(__name__)
app.config["SECRET_KEY"] = "dev-key"
 
 
@app.route("/set")
def set_value():
    session["favorite_color"] = "blue"
    return "ok"
 
 
@app.route("/get")
def get_value():
    return {"favorite_color": session.get("favorite_color")}

Removing values

python

session.pop("favorite_color", None)

Important constraints

Because Flask’s default session is stored in a cookie:

• keep session data small
• don’t store secrets in sessions (client can read)
• sign integrity is provided, confidentiality is not

How Flask-Login uses session

Flask-Login stores:

• the logged-in user id

in the session so it persists across requests.

The session is a signed cookie, not server storage

Flask keeps the whole session in the cookie, on the user’s machine. Nothing is stored on the server:

diagram Diagram mermaid

  flowchart LR
  V["session['user_id'] = 42"] --> S["serialise to JSON"]
  S --> B["base64 encode"]
  B --> G["sign with SECRET_KEY"]
  G --> C["Set-Cookie: session=payload.timestamp.signature"]
  C --> U["stored in the browser"]
  U --> R["sent back on every request"]
  R --> Vf{"signature valid?"}
  Vf -->|"yes"| L["load the values"]
  Vf -->|"no"| E["ignored - an empty session"]

Measured on a live response:

Set-Cookie

session=eyJyb2xlIjoiYWRtaW4iLCJ1c2VyX2lkIjo0Mn0.anhgvw.p1ahivGni_gpokhyDbSbrS2-QhY; HttpOnly; Path=/

Three dot-separated segments: payload, timestamp, signature.

Anyone can read it

decode.py

import base64
payload = cookie_value.split(".")[0]
base64.urlsafe_b64decode(payload + "==")
# b'{"role":"admin","user_id":42}'

Measured — that is the actual decoded content, with no key and no effort. The payload is base64, which is an encoding, not encryption.

The session is readable, so never put a secret in it

No API tokens, no password hashes, no internal notes, no personal data you would not show the user. Storing user_id is fine — the user already knows who they are. Storing is_admin is fine too, because they cannot change it. Storing card_last4 or internal_risk_score hands it to them.

They cannot change it

The signature covers the payload, so a modified payload no longer verifies:

forge.py

# swap the payload for {"user_id": 1, "role": "admin"}, keep the original signature
client.set_cookie("session", forged)
client.get("/whoami")      # -> 'None None'

Measured: the forged cookie was rejected entirely and the session came back empty — not an error, just no values. Tampering downgrades an attacker to an anonymous visitor.

That guarantee rests entirely on SECRET_KEY:

rotate.py

app.config["SECRET_KEY"] = "a-different-key"
client.get("/whoami")      # -> 'None None'   every existing session is now invalid

Measured. Rotating the key logs everybody out — which is the emergency response if it ever leaks, and the reason it must be stable across restarts and identical across every worker process. A key generated at startup means users are logged out whenever you deploy.

Working with it

views.py

from flask import session
 
session["user_id"] = user.id      # set
session.get("user_id")            # read, None if absent
session.pop("user_id", None)      # remove one key
session.clear()                   # log out completely
 
session.permanent = True          # honour PERMANENT_SESSION_LIFETIME
app.config["PERMANENT_SESSION_LIFETIME"] = timedelta(days=7)

Without session.permanent, the cookie is a session cookie: it disappears when the browser closes.

cookie_flags.py

app.config.update(
    SESSION_COOKIE_HTTPONLY=True,   # default: JavaScript cannot read it
    SESSION_COOKIE_SECURE=True,     # HTTPS only — set this in production
    SESSION_COOKIE_SAMESITE="Lax",  # limits cross-site sending
)

HttpOnly is on by default, and appeared in the measured header above. Secure is not — without it the cookie is sent over plain HTTP, where anyone on the network can copy it and use it, since a stolen cookie is as good as the password.

See it move

sketch What is actually in your session cookie p5.js Pause Restart

The payload is base64, readable by anyone holding the cookie. The signature stops it being changed, but does not hide it.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. Where does Flask store the contents of the session by default?

   A in server memory, keyed by a session id in the cookie B in the cookie itself, serialised and signed with SECRET_KEY C in the configured database D in a temporary file per user
   pch.quizShowAnswer

   B — in the cookie itself, serialised and signed with SECRET_KEY — The cookie carries payload, timestamp and signature. Nothing is kept server-side, which is why the session survives a restart and why its size is limited by the 4 KB cookie limit.

2. The first segment of a session cookie base64-decodes to the JSON with role admin and user_id 42. What follows?

   A the cookie is broken; it should be unreadable B the session is signed but not encrypted, so anyone holding the cookie can read every value in it C the signature failed to apply D only the server can perform that decode
   pch.quizShowAnswer

   B — the session is signed but not encrypted, so anyone holding the cookie can read every value in it — base64 is an encoding, not encryption. Store identity such as user_id, never anything the user should not see.

3. An attacker replaces the payload with their own JSON and keeps the original signature. What does the app see?

   A the forged values, since the signature is not checked on every request B an empty session; the signature no longer matches the payload, so the cookie is ignored C a 400 Bad Request D the original values from before the change
   pch.quizShowAnswer

   B — an empty session; the signature no longer matches the payload, so the cookie is ignored — Measured: the forged cookie produced None for every key. Tampering reduces an attacker to an anonymous visitor rather than raising an error.

4. What happens to existing sessions when SECRET_KEY changes?

   A nothing; the key is only used for new sessions B every existing session becomes invalid, so all users are logged out C sessions are re-signed automatically on the next request D only sessions created since the last restart are affected
   pch.quizShowAnswer

   B — every existing session becomes invalid, so all users are logged out — Measured: the same client read None after the key changed. That is the emergency response if the key leaks, and the reason a key generated at startup logs everyone out on each deploy.