API и запросы
Атаки, которые используют форму запроса или доверие браузера к твоему сайту. Их легко пропустить, потому что обычный клиент их никогда не отправляет.
Чек-лист
- Защищай запросы, меняющие состояние, от CSRF. Если аутентифицируешь через cookie, каждому эндпоинту, меняющему состояние, нужен CSRF-токен или строгая политика SameSite cookie. Если аутентифицируешь через bearer-токен в заголовке Authorization (а не через неявную cookie), классический CSRF не применяется, и это одна из причин предпочесть такой подход.
- Закрывай login-CSRF. Даже процесс входа можно подделать: привяжи OAuth
stateк браузеру через cookie, установленную на старте и проверенную на callback. См. аутентификацию. - Ужесточай CORS. Никогда не отражай произвольный
Originи никогда не отправляйAccess-Control-Allow-Origin: *вместе с credentials. Используй явный allowlist origin и только нужные методы и заголовки. Настройка "разрешить всё" по умолчанию - частая ошибка из шаблонов. - Останови mass assignment. Не передавай тело запроса напрямую в обновление базы. Принимай явный allowlist полей, доступных для записи, чтобы пользователь не мог отправить
{"role":"admin"}или{"plan":"enterprise"}и повысить свои права. Помечай поля только для чтения и игнорируй неизвестные. - Выдавай привилегии и платный статус только из доверенного события. План или баланс кредитов должны меняться по проверенному webhook оплаты или по действию админа, а никогда по значению из пользовательского запроса.
- Проверяй webhook. Проверяй подпись провайдера по сырому телу, убеждайся, что сумма и валюта совпадают с ожидаемыми, и делай каждое событие идемпотентным, чтобы повтор не применился дважды.
- Валидируй content types и размеры. Отклоняй неожиданные content types и ограничивай размер тела до парсинга.
Как тестировать
- Добавь
role,is_admin,planилиcreditsв запрос обновления и убедись, что сервер их игнорирует. - Отправь кросс-доменный запрос и убедись, что CORS не отражает твой origin.
- Повтори webhook дважды и убедись, что он применился один раз.