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

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

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

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

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

  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 для login/logout/refresh flow.
  2. Подготовьте таблицу: где хранить токены для 3 типов приложений (SPA, BFF, mobile web).
  3. Опишите единый error-contract для auth-ошибок и правила логирования без секретов.
  4. Проведите tabletop-упражнение по инциденту «утечка refresh token».
  5. Закрепите материал в Node.js вопросах и NestJS вопросах.
  6. Проверьте login/refresh/logout flow в Песочнице и отметьте точки риска XSS/CSRF.

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

  1. Треки: Junior трек, Middle трек, Senior трек.
  2. Вопросы: Junior JavaScript, Senior Frontend, Playbook.
  3. Повторение: 3-5 вопросов без подсказок -> сверка с модулем -> повтор через 24 часа.

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

Вы объясняете security-решения через модель угроз, эксплуатацию и конкретные защитные механизмы, а не через общие фразы.

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

  1. Threat model документация для auth-потока.
  2. Security checklist релиза (с ролями и критериями прохождения).
  3. Incident playbook для сценария утечки токена/ключа.
  4. Набор из 8 сильных ответов на auth/security вопросы.

Куда дальше​

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