Перейти к основному содержимому

Безопасность и хранение

Для чего модуль​

Научиться принимать решения по безопасности не по мифам, а через модель угроз: какие активы защищаем, от кого защищаем, и какой ценой.

Результат после прохождения​

  1. Вы уверенно различаете AuthN, AuthZ, session management и token lifecycle.
  2. Вы проектируете хранение токенов с учетом XSS/CSRF-рисков, а не по «популярному совету».
  3. Вы умеете объяснить и внедрить базовый security baseline для frontend/fullstack продукта.
  4. Вы знаете, что делать в первый час после security-инцидента.

Термины и аббревиатуры​

ТерминКоротко
AuthNПроверка личности
AuthZПроверка прав
JWTПодписанный токен
BFFBackend for Frontend
XSSВнедрение скрипта
CSRFПодделка запроса

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. Каждый урок проходите через призму одного продукта (например, личный кабинет, админка, B2C SPA).
  2. На каждую тему фиксируйте: решение, какой риск закрывает, какие новые риски создает.
  3. После каждого урока обновляйте threat model и checklist релиза.

Программа модуля​

Урок 1. Auth-модели​

Цель: выбирать auth-подход не по тренду, а по требованиям продукта и рискам.

Что нужно различать​

  1. AuthN: кто пользователь.
  2. AuthZ: что ему разрешено.
  3. Session management: как долго и где живет авторизованное состояние.

Session vs JWT vs BFF​

Session (stateful):

  1. Плюсы: централизованная инвалидция, проще revoke.
  2. Минусы: хранение сессионного состояния на сервере/в кэше.

JWT (часто stateless):

  1. Плюсы: масштабирование без общего session store.
  2. Минусы: revoke сложнее, ошибки в lifecycle токенов стоят дорого.

BFF:

  1. Плюсы: токены скрыты от браузера, лучше контроль boundary.
  2. Минусы: добавляется отдельный слой и операционная сложность.

Access/Refresh lifecycle​

Базовая схема:

  1. Короткоживущий access token.
  2. Долгоживущий refresh token с ротацией.
  3. Явные правила revoke при logout, compromise, смене пароля.
  1. HttpOnly: JS не читает cookie.
  2. Secure: только HTTPS.
  3. SameSite: базовая защита от CSRF для cookie-сценариев.
Set-Cookie: refresh_token=...; HttpOnly; Secure; SameSite=Lax; Path=/auth/refresh

Где ломается в проде​

  1. Нет централизованной стратегии revoke.
  2. Access token живет слишком долго «ради удобства».
  3. Logout удаляет только UI-state, но не серверную сессию.

Мини-задача (обязательная)​

Сравните два сценария: SPA без BFF и SPA + BFF. Для каждого опишите: где хранится auth state, как делается refresh, как выполняется logout/revoke.

Что спросит интервьюер: когда cookie-based подход безопаснее, а когда удобнее токены в header.

Критерий готовности по уроку: вы можете выбрать auth-модель под конкретный продукт и защитить выбор через риски и эксплуатационные ограничения.

Урок 2. Хранение и клиентская безопасность​

Цель: понимать, где и почему происходят утечки токенов на клиенте.

Storage options и риски​

localStorage:

  1. Удобен для чтения из JS.
  2. Уязвим при XSS: украсть токен просто.

sessionStorage:

  1. Живет в пределах вкладки.
  2. Проблема XSS остается.

HttpOnly cookie:

  1. JS не читает токен.
  2. Требует правильной защиты от CSRF.

XSS как главный практический риск​

Если в приложении XSS, злоумышленник может:

  1. Читать токены из JS-доступного хранилища.
  2. Вызывать API от лица пользователя.
  3. Экспортировать чувствительные данные.

Минимальный baseline:

  1. Не рендерить непроверенный HTML.
  2. CSP + безопасные шаблоны рендера.
  3. Никаких секретов в client bundle и console logs.

Data minimization и логирование​

  1. Не логируйте токены, session id, PII в открытом виде.
  2. Маскируйте чувствительные поля.
  3. В error-логах храните traceId, но не секреты.

Где ломается в проде​

  1. Refresh token кладут в localStorage «временно», и это остается навсегда.
  2. Логи фронта уходят во внешний сервис с чувствительными данными.
  3. В CSP оставляют слишком широкие script-src.

Мини-задача (обязательная)​

Сделайте таблицу хранения секретов для вашего проекта: что хранится, где хранится, почему именно так, какой риск и как он смягчается.

Что спросит интервьюер: почему хранить refresh token в localStorage опасно.

Критерий готовности по уроку: вы можете обосновать storage-решение с учетом XSS/CSRF/операционки, а не только удобства разработки.

Урок 3. CSRF, CORS и защита API​

Цель: отделять браузерные ограничения от контроля доступа и защиты бизнес-операций.

Что CORS не решает​

CORS управляет тем, может ли браузер читать ответ cross-origin. Это не авторизация и не полноценная защита API.

CSRF mitigation​

Для cookie-based auth защищайтесь комбинацией:

  1. SameSite.
  2. CSRF token (synchronizer/double-submit).
  3. Проверка Origin/Referer для критичных mutation endpoint.

Защита mutation API​

Минимальный baseline:

  1. AuthZ на сервере для каждого действия.
  2. Rate limiting и anti-abuse для чувствительных endpoint.
  3. Idempotency key для критичных повторяемых операций (платежи, заказы).

Пример CORS-конфига (идея)​

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,OPTIONS
Vary: Origin

Важно: при Allow-Credentials: true нельзя использовать Allow-Origin: *.

Где ломается в проде​

  1. Включают * «на время отладки» и забывают убрать.
  2. CORS воспринимают как замену серверной AuthZ.
  3. Нет rate limiting для login/reset endpoints.

Мини-задача (обязательная)​

Опишите схему защиты для двух endpoint: POST /auth/login и POST /payments/confirm. Добавьте: auth, csrf, rate limiting, audit logging, idempotency.

Что спросит интервьюер: почему «включить * в CORS» не решает безопасность и часто вредит.

Критерий готовности по уроку: вы можете спроектировать защиту API так, чтобы она покрывала и браузерные, и серверные векторы атак.

Урок 4. Безопасные практики релиза​

Цель: превратить безопасность в процесс команды, а не в разовую проверку.

Security baseline перед релизом​

  1. Secrets только через защищенные env/secret manager.
  2. Dependency audit и фиксация критичных уязвимостей.
  3. Проверка CSP/headers (X-Frame-Options, Referrer-Policy, HSTS).
  4. Проверка auth flows: login, refresh, logout, revoke.

Incident response: первый час​

  1. Классифицировать инцидент: что утекло, кто затронут, текущий радиус поражения.
  2. Снизить ущерб: revoke токенов/ключей, ограничение risky endpoint.
  3. Собрать фактологию: таймлайн, trace id, affected services.
  4. Коммуникация: внутренняя и внешняя, без домыслов.

После инцидента​

  1. Postmortem: root cause + corrective actions + preventive actions.
  2. Обновление чеклистов и автоматизированных проверок.
  3. Проверка, что риск реально снижен, а не «документация обновлена».

Мини-задача (обязательная)​

Сделайте pre-release security checklist (минимум 15 пунктов) и incident-playbook (первый час). Привяжите каждый пункт к роли: frontend, backend, devops, security.

Что спросит интервьюер: какие 3 шага вы сделаете в первый час после security-инцидента.

Критерий готовности по уроку: вы можете провести релиз по security-checklist и показать, какие риски этим реально закрываются.

Практика​

1. Threat model для auth/session flow​

Связка: Senior q-11, Node q-14, Nest q-7.

Что сделать:

  1. Опишите flow login -> refresh -> logout -> revoke для SPA, BFF и mobile web.
  2. Заполните таблицу surface -> asset -> attacker action -> client control -> server control -> evidence -> owner.
  3. Отдельно отметьте XSS, CSRF, token theft, token replay, session fixation и missing AuthZ.

Артефакт: frontend/backend threat model для auth flow.

Критерий готовности: вы называете, что контролирует frontend, что обязан проверять server, и где frontend validation не является security boundary.

2. Storage и token policy​

Связка: Junior JS q-18, Senior q-11, строка Browser storage and CORS в Practice Bridges.

Что сделать:

  1. Заполните таблицу для theme, draft form, access token, refresh token, csrf token: storage -> lifetime -> JS-readable? -> XSS risk -> CSRF risk -> mitigation.
  2. Для SPA, BFF и mobile web выберите session strategy и назовите trade-off.
  3. Проверьте login/refresh/logout flow как free-practice: где токен появляется, где исчезает, что логируется, что не логируется.

Артефакт: storage/token policy table.

Критерий готовности: вы не отвечаете "localStorage плохо, cookie хорошо" шаблоном, а объясняете threat model, lifetime, CSRF controls и server-side checks.

3. Auth error contract и safe logging​

Связка: Node q-7, Node q-10, Nest q-19.

Что сделать:

  1. Опишите public auth errors: UNAUTHENTICATED, FORBIDDEN, SESSION_EXPIRED, TOKEN_REVOKED, RATE_LIMITED.
  2. Для каждого укажите HTTP meaning, safe message, UI action, retryability, requestId and logs.
  3. Составьте do not log список: raw token, cookie, password, provider payload, private user data, stack trace in client response.

Артефакт: auth error contract + safe logging checklist.

Критерий готовности: вы можете показать пользователю понятное действие и одновременно не раскрыть детали, полезные атакующему.

4. Incident tabletop: утечка refresh token​

Связка: Senior q-12, Senior q-13, Node q-9.

Что сделать:

  1. Проведите tabletop на первый час инцидента: detect, scope, contain, revoke, communicate, monitor.
  2. Привяжите действия к ролям: frontend, backend, devops, security, support/product.
  3. Добавьте stop conditions: когда отключить endpoint, включить rate limit, отозвать токены, остановить rollout.

Артефакт: incident playbook refresh token leak: first hour.

Критерий готовности: вы не говорите "пофиксим и напишем postmortem", а показываете порядок снижения ущерба и доказательство, что риск реально закрыт.

Связь с треками и вопросами​

  1. Browser/session basics: Junior JS q-18..q-20.
  2. Frontend security: Senior q-11, Senior q-12, Senior q-13.
  3. Backend/auth boundary: Node q-7, Node q-9, Node q-10, Node q-14, Nest q-7, Nest q-19.
  4. Повторение: через 24 часа без подсказок восстановите threat model и storage/token policy, затем проверьте себя по Playbook.

Критерий готовности​

Ready: вы объясняете security-решения через threat model, exploit path, client/server controls, logging policy и incident response.

Partial: вы знаете XSS/CSRF/JWT определения, но не можете выбрать storage strategy или показать, где server обязан проверить AuthZ.

Not ready: вы предлагаете "спрятать кнопку", "включить CORS", "положить токен куда удобнее" или логировать raw token/debug payload.

Артефакты после модуля​

  1. Threat model для login -> refresh -> logout -> revoke.
  2. Storage/token policy table для SPA, BFF и mobile web.
  3. Auth error contract + safe logging checklist.
  4. Pre-release security checklist с ролями и pass/fail criteria.
  5. Incident playbook refresh token leak: first hour.

Куда дальше​

  1. Web и сеть
  2. Node.js
  3. Безопасность и хранение