Как работает cookie

Что проверяют

Понимаете ли вы, что cookie это не «файл на компьютере», а механизм HTTP: сервер присылает заголовок, браузер хранит пару и сам подставляет её в следующие запросы. Следом почти всегда спрашивают про безопасность сессионной куки и про отличие от токена в localStorage.

Как отвечать

Опишите цикл: сервер отвечает заголовком Set-Cookie: sessionid=abc; Path=/; HttpOnly; Secure; SameSite=Lax, браузер сохраняет запись и в каждый запрос к подходящему домену и пути добавляет Cookie: sessionid=abc. Обычно в куке лежат не сами данные, а идентификатор сессии, данные хранятся на сервере.

Атрибуты, которые стоит назвать:

• Expires / Max-Age: без них кука сессионная и живёт до закрытия браузера, с ними постоянная;
• Domain и Path: область отправки. Без Domain кука привязана строго к хосту, который её выдал;
• HttpOnly: скрипт не видит куку через document.cookie, это снижает ущерб от XSS;
• Secure: только по HTTPS;
• SameSite: Strict, Lax или None, защита от CSRF. Chrome считает куку без атрибута Lax, а None работает только вместе с Secure.

Дальше покажите Python. В Django сессия по умолчанию лежит в базе, в куке sessionid только ключ, флаги задаются настройками SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SAMESITE. Во Flask response.set_cookie() принимает httponly, secure, samesite, а встроенная session подписана SECRET_KEY, но не зашифрована. В FastAPI это Response.set_cookie из Starlette.

Добавьте про размер: около 4 КБ на куку, и все куки домена едут в каждом запросе, включая статику.

Где спотыкаются

Называют cookie файлом, который сервер «кладёт на диск». Где хранить, решает браузер, сервер лишь просит его об этом в заголовке.

Считают, что подписанная сессия Flask скрывает содержимое. Её можно декодировать из base64 и прочитать, подпись защищает только от подмены, поэтому секреты туда не кладут.

Путают защиту: HttpOnly не спасает от CSRF, а SameSite не спасает от XSS. Нужна комбинация, плюс CSRF-токен там, где Lax недостаточно.