Cookies и сессии
Тема дорожной карты · Backend разработчик
Сессионная аутентификация — это stateful-подход к управлению идентичностью пользователя, при котором сервер создаёт запись сессии при входе, сохраняет её в серверном хранилище и отправляет клиенту ID сессии в заголовке ответа Set-Cookie, который предъявляется при каждом последующем запросе. Хранилищем сессий обычно является Redis (express-session с адаптером connect-redis в Node.js или django.contrib.sessions с бэкендом django-redis в Python/Django) — это гарантирует сохранение сессий после перезапуска приложения и их совместное использование между горизонтально масштабируемыми подами в Kubernetes. В отличие от JWT-аутентификации, сессионная аутентификация допускает немедленную инвалидацию сессии — вызов req.session.destroy() или del request.session мгновенно делает сессию недействительной, — что предпочтительно для высокозащищённых приложений, таких как банковские системы или административные панели. Сессионные куки должны быть настроены с флагами HttpOnly (блокирует доступ JavaScript), Secure (только HTTPS), SameSite=Strict или SameSite=Lax (защита от CSRF), а также с разумным Max-Age или Expires для ограничения ущерба от кражи куки. Атаки через фиксацию сессии нейтрализуются перегенерацией ID сессии после успешной аутентификации (req.session.regenerate() в Express, request.session.cycle_key() в Django).
Как это работает
Cookies и сессии включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная auth: OAuth 2.0 + OpenID Connect для делегированной identity, session-куки для традиционных веб-приложений, JWT для stateless distributed-систем. Пароли всегда хешируйте через bcrypt или argon2id. CSRF-защита на state-changing endpoints; CORS осознанно (не * в production). Авторизация: RBAC (роли), ABAC (атрибуты), policy engines (OPA, Casbin). MFA/2FA для любой привилегированной операции.
Когда применять
Session-куки — для монолитных веб-приложений (HttpOnly + Secure + SameSite=Lax): проще, отзываемо, server-side state. JWT — только когда реально нужна stateless distributed-валидация; иначе session безопаснее. Identity отдавайте провайдеру (Yandex ID, Keycloak, Auth0, Authentik) — DIY identity = место утечек. Rate-limit на auth-endpoints с первого дня.
Типичные ошибки
Ловушки Cookies и сессии: пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.