Защита API: Rate Limiting, CORS и JWT
Суть без длинного чтения
Если нужен быстрый вывод по теме, ниже собрали главное: что это значит, когда проблема уже влияет на бизнес и какой следующий шаг обычно даёт пользу быстрее всего.
О чем статья
Базовые гигиенические минимумы для любого публичного API: как не дать положить сервер брутфорсом.
В какой момент это становится проблемой
Повод разбираться глубже появляется, когда у продукта есть внешние API, несколько ролей доступа, чувствительные данные или частые релизы без понятного контура контроля.
Что делать после прочтения
Проверим API, права доступа, release-процесс и эксплуатационный контур, чтобы вы получили приоритизацию рисков и понятную первую очередь работ.
#01Хранение JWT токенов
Никогда не храните JWT (Access токен) в LocalStorage! Это прямая дорога к XSS уязвимостям — любой вредоносный скрипт на сайте сможет украсть сессию пользователя.
Правильный путь: Отправлять токен в куках с флагами HttpOnly, Secure и SameSite=Strict. Тогда JavaScript не будет иметь к ним доступа.
#02Rate Limiting (Троттлинг)
Защита от брутфорса паролей и DDoS на уровне приложения. В NestJS это делается пакетом @nestjs/throttler. Мы жестко лимитируем эндпоинты авторизации (например, не более 5 попыток в минуту с одного IP).
#03IDOR уязвимости
Insecure Direct Object Reference. Если у вас есть роут /api/orders/123, вы обязаны проверить, принадлежит ли заказ №123 текущему авторизованному пользователю. Иначе кто угодно сможет перебрать ID и скачать чужие данные.
Редакционная проверка и источники
Материал подготовлен как практический разбор и привязан к рабочим сценариям бизнеса, а не к абстрактной теории.
Что ещё посмотреть по этой задаче
Ниже материалы, которые помогают перейти от общего понимания проблемы к более предметному следующему шагу.
Типовые уязвимости в API, личных кабинетах и B2B-системах
Главные риски в B2B и личных кабинетах редко выглядят как “голливудский взлом”. Обычно это тихие ошибки в доступах, API и бизнес-логике, которые долго остаются незаметными.
Когда пентест бесполезен без плана исправлений
Пентест сам по себе не делает систему безопасной. Без ownership, приоритизации и реального плана исправлений он часто превращается в дорогой PDF, который не меняет риск-профиль бизнеса.
Как понять, что веб-система уже создаёт риск для бизнеса
Система может не падать каждый день и всё равно быть опасной для бизнеса. Риск часто накапливается в доступах, релизах, слабом ownership и технических привычках команды.
Куда идти после прочтения
Здесь не теория ради теории. Ниже собрали, какая услуга чаще всего решает похожую задачу на практике и какой кейс стоит открыть, если хотите быстро понять формат результата.
Технический аудит и план стабилизации web-проекта
Аудит текущего web-проекта с картой рисков, приоритетами и планом первой очереди.
Становится понятно, что именно нужно проверить в первую очередь: продукт, интеграции, инфраструктуру или работу подрядчиков.
Вы получаете список проблем по критичности: что уже бьёт по выручке и стабильности, а что можно оставить на второй этап.
Нужен security-разбор, который заканчивается не списком страшилок, а реальным планом исправлений?
Проверим API, права доступа, release-процесс и эксплуатационный контур, чтобы вы получили приоритизацию рисков и понятную первую очередь работ.
Технический аудит и план стабилизации web-проекта
Аудит текущего web-проекта с картой рисков, приоритетами и планом первой очереди.