sottoСемантика HTTP
Методы несут смысл: GET/HEAD безопасны (safe — только чтение, без побочных эффектов); GET, PUT, DELETE идемпотентны (повтор не меняет результат), а POST — нет. Это важно для кэширования и ретраев (см. урок про REST API для статус-кодов и идемпотентности).
GET-ответы кэшируемы, и кэшированием управляют заголовки: Cache-Control (можно ли и сколько кэшировать), ETag/If-None-Match и Last-Modified/If-Modified-Since для условных запросов (сервер отвечает 304 Not Modified, экономя трафик).
Cookies
Cookie хранится у клиента и автоматически прикрепляется браузером к запросам на подходящий домен/path. Это удобно для сессий, но именно автоматичность делает cookie мишенью атак.
Флаги безопасности обязательны: HttpOnly (cookie недоступна из JS — снижает кражу при XSS), Secure (отправляется только по HTTPS), SameSite=Lax/Strict (ограничивает отправку в кросс-сайтовых запросах — защита от части CSRF). Плюс Domain/Path/Max-Age/Expires управляют областью и сроком жизни.
ResponseCookie c = ResponseCookie.from("SESSION", id)
.httpOnly(true).secure(true).sameSite("Lax").path("/").build();Сессии: stateful против stateless
Stateful (server-side session): состояние пользователя хранится на сервере, а cookie несёт только session id. Просто, но плохо масштабируется — при нескольких инстансах нужны sticky sessions или общий стор сессий (Redis), плюс расход памяти.
Stateless: сервер не хранит сессию, а доверие подтверждается токеном (обычно JWT) в заголовке Authorization при каждом запросе. Масштабируется горизонтально без общего хранилища, но отзыв/инвалидация токена сложнее (это разбирается в уроке про JWT/OAuth2).
HTTPS/TLS
HTTP передаётся открытым текстом, поэтому в проде используют HTTPS (HTTP поверх TLS): шифрование транзита защищает от перехвата и подмены, а сертификат подтверждает подлинность сервера.
Заголовок HSTS (Strict-Transport-Security) заставляет браузер всегда ходить по HTTPS. Без TLS любые токены и cookie можно перехватить — поэтому Secure-cookie и bearer-токены имеют смысл только поверх HTTPS.
Аутентификация против авторизации
Это два разных вопроса. Authentication — «кто ты» (пароль, токен, сертификат, session id). Authorization — «что тебе можно» (роль, право, владение конкретным ресурсом). Сначала authn, потом authz.
Типичная ошибка уровня senior — проверить только роль и забыть про ownership: пользователь с ролью USER не должен редактировать ЧУЖОЙ заказ, даже имея право редактировать заказы вообще. Реализацию обоих в Spring разбираем в следующих уроках.
Как отвечать на собеседовании
Назовите safe/idempotent методы и кэширование (Cache-Control/ETag/304). Разберите флаги cookie (HttpOnly/Secure/SameSite) и зачем каждый. Сравните stateful (общий стор/sticky) и stateless (токен, масштаб, но отзыв сложнее) сессии. Подчеркните HTTPS как основу и чёткую границу authn/authz с ловушкой ownership.