Руководства по безопасности
Ограничение частоты запросов и защита от злоупотреблений: лимиты против перебора паролей и неконтролируемых расходов
Ограничение частоты (rate limiting) — это решение о том, кого считать, что считать и что происходит у предела. NIST ограничивает неудачные попытки подряд сотней и предупреждает, что жёсткая блокировка лишает доступа настоящих пользователей, а OWASP включает в лимиты API ограничения расходов.
Ограничение частоты обычно не срабатывает не потому, что лимит слишком мягкий, а потому, что задан не тот вопрос. Прежде чем решать «сколько в минуту», нужно ответить на три вопроса: кого вы считаете, что вы считаете и что происходит при достижении предела.
Вопрос 1: кого вы считаете?
Если сделать IP основой, это не работает ни против атакующих, ни для законных пользователей
Со стороны атакующего: за обратным прокси или CDN адрес источника, который видит приложение, может быть значением из заголовка. Если безусловно доверять X-Forwarded-For, то чтобы вас посчитали кем-то другим, достаточно переписать заголовок. Вы думаете, что считаете, а не считаете ничего. Насколько можно доверять этому заголовку, разобрано в статье подделка X-Forwarded-For и доверенные прокси.
Со стороны законных пользователей: из-за корпоративного NAT и мобильных сетей один адрес делят много посторонних друг другу людей. Ограничивая по IP, вы ограничиваете тех, кто вас не атакует.
Поэтому основой должен быть идентификатор, связанный с тем, кто действует, — аккаунт, API-ключ, установленная сессия, — а IP добавляется как вспомогательный сигнал. На этапах без аутентификации (до входа) такого идентификатора нет, и это должны закрыть следующие два вопроса.
Вопрос 2: что вы считаете?
Схема, которая считает только запросы, не может остановить один дорогой запрос. OWASP API Security Top 10 в пункте API4:2023 «Unrestricted Resource Consumption» (неограниченное потребление ресурсов) прямо перечисляет, чему нужен предел.
Что вы считаете
Запросы: 100/мин → в пределах лимита ✓
↓ а на самом деле расходуется
CPU · время
полный перебор на каждый вызов
Память
слишком большие входные данные
Трафик
десять тысяч записей
Деньги
повторные платные вызовы
= исчерпано, так и не дойдя до предела
- Время и память
- Тайм-ауты выполнения, максимальный объём выделяемой памяти
- Ресурсы ОС
- Число файловых дескрипторов, число процессов
- Размер входных данных
- Максимальный размер загружаемого файла, максимальный размер входных параметров
- Работа на один запрос
- Число операций, выполняемых в одном запросе клиента API, число записей на страницу
- Деньги
- Лимиты расходов у сторонних поставщиков и интеграций API (см. ниже; последний рубеж против финансового ущерба)
Соблюдение «100 запросов в минуту» ничего не защищает, если один запрос возвращает десять тысяч записей, обрабатывает огромный файл или делает несколько вызовов платного внешнего API. Подбирайте единицу подсчёта под то, что защищаете, — CPU, память, трафик, деньги. В этом суть проектирования.
Вопрос 3: что происходит у предела?
Эту часть понимают неправильно чаще всего. Строже — не значит автоматически безопаснее.
Побочный эффект грубой блокировки
«Три ошибки — и аккаунт заморожен» кажется правильным, но это значит, что атакующий может намеренно замораживать чужие аккаунты: вы превратили блокировку в инструмент отказа в обслуживании против своих же пользователей. Вы остановили перебор, но выпустили способ лишать людей доступа.
Проектирование по принципу «не стоит усилий»
Замедляйте попытки, а не блокируйте доступ. Что перечисляет NIST SP 800-63B: CAPTCHA перед аутентификацией, ожидание после неудачной попытки, растущее по мере приближения аккаунта к максимуму, список разрешённых IP-адресов, с которых пользователь уже входил, и методы на основе риска или адаптивные методы, оценивающие, укладывается ли поведение в обычные рамки (адрес, геолокация, время, метаданные браузера).
Число NIST больше, чем ожидают: 100 неудачных попыток подряд
NIST SP 800-63B указывает: «проверяющая сторона ОБЯЗАНА ограничивать число неудачных попыток аутентификации подряд для одного аккаунта не более чем сотней». Привычное «блокировать после трёх» стандарт не требует.
Почему 100 достаточно: когда на пути стоят задержки и CAPTCHA, дойти до 100 за разумное время становится непрактично. Иначе говоря, ужесточать счётчик без задержек — худший вариант: законные пользователи теряют доступ, а автоматическая атака всё так же быстро расходует свои попытки.
Ещё одно практическое указание из того же документа: после успешной аутентификации проверяющей стороне СЛЕДУЕТ не учитывать предыдущие неудачные попытки этого пользователя с того же IP-адреса. Решите и то, когда счётчик сбрасывается, — это тоже часть проектирования.
Где что применять
Вход (перебор паролей и подстановка учётных данных)
Сделайте основой счётчик неудач по аккаунту и постепенно увеличивайте задержку. IP используйте как вспомогательный сигнал, но никогда как единственную основу. С многофакторной аутентификацией правильный пароль не даёт доступ сразу, и угадывание перестаёт окупаться. Учтите также, что в последнее время проникновения всё чаще происходят с действительными учётными данными, а не через угадывание (анализ путей проникновения 2026 года, на английском): ограничение частоты необходимо, но недостаточно.
Сброс пароля и письма с подтверждением (почтовая бомбардировка)
Считайте и то, что может запустить отправку, и число писем на один адрес. Форма, принимающая чужой адрес, позволяет атакующему одновременно преследовать третье лицо и портить вашу репутацию отправителя. Сочетайте паузу для каждого адреса получателя, минимальный интервал повторной отправки и удаление неподтверждённых записей (это заодно уменьшает объём непроверенных персональных данных у вас). О самом процессе сброса — в статье ошибки в сбросе пароля.
Публичные точки доступа и функции с ИИ (всплески расходов)
Считайте стоимость, а не запросы. Ограничьте размер входных данных, число операций на запрос и обязательно настройте лимит расходов на стороне поставщика. Среди сценариев OWASP есть счёт, выросший с 13 до 8 000 долларов в месяц. Подключая платный внешний API к публичной функции, убедитесь, что есть уровень, который держится, даже когда ваш код ошибается. Что бывает при утечке ключа — в статьях украденный ключ, счёт и заблокированный аккаунт и утечка API-ключа из кода, написанного ИИ.
Дорогие операции (поиск, экспорт, обработка файлов)
Задайте явные пределы для времени выполнения, памяти, размера загрузки и числа записей на страницу. Где нет предела, один запрос может исчерпать ваши ресурсы. Ограничьте память, CPU и число процессов и на уровне контейнера или serverless, чтобы приложение, потребляющее неожиданно много, останавливали снаружи.
Знайте, когда предел достигается
Лимит, который нельзя наблюдать, — это половина меры. Если никто не видит, что предел достигается, вы не заметите ни идущую атаку, ни то, что законные пользователи потеряли доступ. Записывайте, как часто срабатывают лимиты, и настройте оповещение о резком росте. Это состояние «способны заметить, что что-то не так» из статьи базовый уровень безопасности для организаций, применённое здесь.
Взгляд этого сайта: цель лимита — сделать злоупотребление невыгодным
Если считать, что ограничение частоты должно полностью блокировать атаки, вы застрянете на вопросе, на который нет ответа: сколько попыток безопасно? Мы смотрим иначе: речь о затратах и выгоде атакующего. Повышайте затраты атакующего на каждую попытку (время, вычисления, CAPTCHA, второй фактор) и снижайте ожидаемую выгоду от каждой попытки (шанс попадания, как далеко попадание его продвинет). Не нужно доводить вероятность успеха до нуля — нужно, чтобы атака не окупалась.
Поэтому мы предпочитаем задержки и второй фактор жёсткой блокировке. Единственное исключение — деньги: единственный надёжный предел — это лимит расходов, который находится вне вашего кода. Код иногда ошибается, поэтому поставьте меру вне кода, чтобы даже ошибка не могла привести к неограниченному счёту.
Источники (первичные)
- NIST SP 800-63B, «Digital Identity Guidelines: Authentication and Lifecycle Management» §5.2.2 Rate Limiting (Throttling) — pages.nist.gov (требование SHALL ограничить неудачные попытки подряд не более чем сотней; CAPTCHA, растущее ожидание, списки разрешённых IP и методы на основе риска; рекомендация SHOULD не учитывать прежние неудачи с того же IP после успешного входа)
- OWASP API Security Top 10 2023, «API4:2023 Unrestricted Resource Consumption» — owasp.org (ресурсы, которым нужны лимиты, влияние на расходы и настройка лимитов расходов у сторонних поставщиков)
Что прочитать дальше
- Сравнение крупных случаев 2026 года: что общего у KDDI, Aflac, Цифрового агентства Японии и Sakura Internet (на английском)
- Реальный случай: злоупотребление реестром CPR в Дании (на английском; злоупотребили доступом законного клиента к поиску)
- Реальный случай: утечка Baitoru (до 3,88 млн адресов почты) (на английском; массовый сбор через «ошибку в спецификации» и лимиты записей на пользователя)
- Основа: подделка X-Forwarded-For и доверенные прокси (база для вопроса «кого считать»)
- Проектирование: ошибки в сбросе пароля / как выбрать многофакторную аутентификацию
- Расходы: украденный ключ, счёт и заблокированный аккаунт / утечка API-ключа из кода, написанного ИИ
FAQ
QПосле скольких неудачных входов блокировать аккаунт — трёх? пяти?
NIST SP 800-63B требует, чтобы проверяющая сторона ограничивала число неудачных попыток аутентификации подряд для одного аккаунта не более чем сотней. Три или пять — не требование стандарта. Вместо этого, чтобы не блокировать законных пользователей, тот же документ предлагает CAPTCHA перед аутентификацией, время ожидания, растущее по мере приближения аккаунта к максимуму, список разрешённых IP-адресов, с которых пользователь уже входил, и методы на основе оценки риска или адаптивные методы. Агрессивная блокировка к тому же даёт атакующему способ намеренно замораживать чужие аккаунты. Повышайте стоимость каждой попытки, а не только снижайте их число.
QДостаточно ли ограничения по IP-адресу?
Нет. За обратным прокси или CDN адрес, который видит приложение, может быть не настоящим источником: если безусловно доверять X-Forwarded-For, атакующий становится другим клиентом, просто переписав заголовок, и вы фактически ничего не считаете. А законные пользователи делят адреса через корпоративный NAT и мобильные сети, поэтому лимиты по IP ограничивают и посторонних людей. Основой делайте идентификатор, связанный с тем, кто действует, — аккаунт, API-ключ, установленную сессию, — а IP используйте как вспомогательный сигнал.
QКак остановить бомбардировку письмами с подтверждением?
Нужны и ограничение того, кто может запустить отправку, и подсчёт писем на один и тот же адрес. Если ваша форма принимает чужой адрес, атакующий может через вас преследовать третье лицо и одновременно испортить репутацию отправки вашего домена. Сочетайте паузу для каждого адреса получателя, минимальный интервал между повторными отправками и удаление записей, которые не подтвердили за определённое время, — это заодно уменьшает объём непроверенных персональных данных у вас.
QКакая главная опасность, если поставить AI API за публичную функцию?
Счёт. OWASP API Security Top 10 в пункте API4:2023 Unrestricted Resource Consumption перечисляет лимиты, нужные API, — тайм-ауты выполнения, память, размер загрузки, число операций на запрос — и наряду с ними включает лимиты расходов у сторонних поставщиков. Среди сценариев есть счёт, выросший с 13 до 8 000 долларов в месяц. Ограничение числа запросов не защищает от операций, дорогих по отдельности. Настройте лимит расходов на стороне поставщика: это единственный предел, который держится, даже когда ваш код ошибается.