Кто создает куки?

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

Понимаете ли вы механику HTTP-кук целиком: кто создаёт, кто хранит, кто и когда отправляет обратно. Для Python-бэкендера вопрос быстро переходит к сессиям и безопасности: какие атрибуты вы ставите сессионной куке и почему.

Как отвечать

Создать куку могут несколько сторон, а хранит её всегда браузер:

• сервер: присылает заголовок ответа Set-Cookie. В Django и Flask это response.set_cookie(...), в FastAPI тот же метод из Starlette. Сессионную куку фреймворк ставит сам;
• клиентский JavaScript: через document.cookie. Куку с HttpOnly скрипт не может ни прочитать, ни создать;
• промежуточные узлы: балансировщик или прокси тоже может добавить Set-Cookie, например для липких сессий.

Браузер сохраняет куку и сам отправляет её в заголовке Cookie на подходящие по домену и пути запросы. Сервер читает её через request.COOKIES в Django или request.cookies во Flask и FastAPI.

Атрибуты, о которых спросят обязательно:

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

В Django полезно знать значения по умолчанию: SESSION_COOKIE_HTTPONLY = True, SESSION_COOKIE_SAMESITE = "Lax", а SESSION_COOKIE_SECURE = False, поэтому на проде его включают явно. Размер одной куки ограничен примерно 4 КБ.

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

Говорят, что куки создаёт только сервер, и забывают про document.cookie. Или наоборот думают, что скрипт может выставить HttpOnly.

Считают стандартную сессию Flask зашифрованной. Она подписана SECRET_KEY, подделать её нельзя, но содержимое читается простым декодированием, поэтому секреты туда не кладут.

Путают защиту: HttpOnly не спасает от CSRF. От него защищают SameSite и CSRF-токены, в Django это CsrfViewMiddleware.