Эшелонированная защита: брешь живёт в шве

Флоу входа — образцовый. Пароли хешируются Argon2id, сессия — короткоживущий JWT, TLS принуждается через HSTS, API-ключ лежит в вольте. А потом пользователь меняет id в GET /accounts/{id}/statements и читает чужие банковские выписки. Ни один контроль не сломан. Аутентификация проверила, кто вызывает, — безупречно — а эндпоинт выписок просто никогда не спросил, имеет ли этот вызывающий право читать эту запись. Каждый слой прошёл свой собственный тест. Брешь жила в зазоре между ними.

Один запрос, шесть слоёв

Проследи одно чувствительное действие — залогиненный пользователь переводит деньги — и ты пройдёшь через все контроли, что покрыл трек безопасности. Каждый — отдельный слой со своей задачей, и сеньор рассуждает о них как о стеке, а не как о чек-листе:

1. Транспорт — TLS плюс HSTS, чтобы запрос нельзя было прочитать или даунгрейднуть до открытого текста на проводе.
2. Аутентификация — доказать, кто вызывает. Короткоживущий access-токен (минуты, не дни), пароли хранятся как хеши Argon2id или bcrypt, никогда сам пароль.
3. Авторизация — решить, имеет ли этот вызывающий право делать это с этим объектом. Запрет-по-умолчанию, наименьшие привилегии. Это риск №1 у OWASP не просто так.
4. Обработка ввода — относись к каждому полю как к враждебному: валидируй, параметризуй запросы, кодируй вывод.
5. Секреты — ключи и креды БД живут в вольте или env, никогда в репозитории, никогда в JWT.
6. Цепочка поставок — зависимости, исполняющие всё вышеперечисленное, сами проверены и запинены.

Тезис всего трека приземляется здесь: эшелонированная защита предполагает, что каждый контроль рано или поздно откажет. Ты складываешь их так, чтобы, когда первый барьер падёт, второй замедлил атакующего, а третий поднял тревогу. Ошибка джунов — считать один сильный контроль ответом.

Брешь живёт в шве

Опасные провалы — это не отсутствующий слой, такие ловят на ревью. Это два корректных слоя, которые не композируются. Хук — каноничный пример: аутентификация ответила «да, это валидный залогиненный пользователь», а эндпоинт доверил этому ответу значение «…значит, пусть читает запись», чего аутентификация никогда не утверждала. AuthN — это не AuthZ. Знание, кто человек, не говорит ничего о том, к чему он может прикасаться.

OWASP ставит Broken Access Control на A01 — самый частый серьёзный изъян — именно потому, что он живёт в этих швах. Фикс структурный, а не заплатка на один роут: принуждай авторизацию в доверенном серверном коде, запрещай по умолчанию для каждого непубличного ресурса и проверяй владение записью на объекте, который называет запрос, а не только на роуте. Атакующий, переключающий {id} в GET /accounts/{id}/statements, делает IDOR; останавливает это только сервер, спрашивающий «владеет ли этот субъект этим объектом?» на каждом запросе.

Шов JWT-в-localStorage

Решение о хранении токена — чистая проблема композиции, поэтому заслуживает близкого взгляда. Безупречно выпущенный JWT — подписанный, короткий срок, верные claims — побеждается тем, куда ты его кладёшь. Положи его в localStorage, и любой успешный XSS выполняет localStorage.getItem('token') и эксфильтрует его на сервер атакующего; собственная сила токена нерелевантна, как только JavaScript может его прочитать. Митигация — HttpOnly-кука, которую JavaScript не может тронуть, поэтому XSS её не украдёт — но куки шлются автоматически кросс-сайтово, что вновь открывает CSRF. Это ты закрываешь через SameSite плюс CSRF-токен. Заметь форму: каждый фикс решает один слой и обнажает шов со следующим. Нет единой настройки, которая побеждает; ты композируешь HttpOnly + Secure + SameSite + короткий TTL, и всё равно обязан убить XSS у источника кодированием вывода и CSP, потому что атакующий, способный исполнить скрипт в твоём origin, уже прошёл мимо вопроса хранения.

Наименьшие привилегии везде, не только у двери

Эшелонированная защита — ещё и про радиус взрыва. Когда слой всё же откажет — а модель предполагает, что один откажет, — наименьшие привилегии решают, как далеко расползётся ущерб. Кред из вольта, что использует API, должен давать только те строки и операции, что нужны эндпоинту, чтобы скомпрометированный сервис не осушил всю базу. Access-токен должен быть короткоживущим, чтобы украденный истёк за минуты, а не недели. Зависимость, которую ты подтянул, должна работать под тем же надзором, потому что вредоносный транзитивный пакет исполняется внутри твоей границы доверия. NIST SP 800-63B и руководство OWASP по паролям задают пол для слоя аутентификации — Argon2id, настроенный примерно на 250–500мс на хеш, или bcrypt с cost factor 12+, с уникальной солью на пользователя, — но сильный хеш за эндпоинтом сброса без рейт-лимита всё равно падает. Число на одном слое никогда не оправдывает зазор в следующем.