Защита API

Как и зачем защищаем API и какие шаги вам нужно пройти, чтобы мы настроили защиту под ваши нужды.

Что такое API

API (Application Programming Interface) — это специальный интерфейс, с помощью которого другие программы могут общаться с вашим ресурсом. Люди для «общения» с сайтами и приложениями пользуются графическим интерфейсом – нажимают кнопки на экране, и сайт/приложение выдаёт ответ. Программы делают то же самое через программный интерфейс (API): вместо нажатия кнопок отправляют на сервер запрос и получают ответ.

Пример: пользователь хочет узнать цену кроссовок . Он заходит в интернет-магазин и жмёт на изображение товара. На появившийся карточке видит: «Цена: 12 тыс.». Приложению для сравнения цен на товары тоже нужно узнать, сколько стоят кроссовки. Оно не открывает сайт визуально, а делает API-запрос:

GET /api/v1/products?name=Nike%20Air%20Max HTTP/1.1
Host: http://shop.example.com[shop.example.com
Authorization: Bearer <уникальный токен>

В ответ получает данные о цене в JSON.

Набор правил, по которым программы составляют подобные запросы к вашему сайту/приложению, и URL-адреса, на которые они отправляют запросы, и называется API.

Зачем защищать API

Чтобы не допустить перегрузки сервисов, утечек данных или финансовых потерь, которые могут возникнуть из-за атак через API.

Примеры атак из нашей практики. «Модульбанк» атаковали методами credential stuffing и SMS-бомбинг:

Credential stuffing: боты подставляли утёкшие в сеть пары логин+пароль и пытались авторизоваться в личных кабинетах клиентов. За 5 дней боты предприняли 4 млн попыток.
SMS-бомбинг: при авторизации/регистрации в веб-приложении банка клиенту проходит SMS. Через API боты злоумышленников заваливали банк фейковыми запросами — и банк тратил сотни тысяч рублей в месяц на SMS не реальным клиентам, а в никуда.

Антибот заблокировал запросы злоумышленников, банк перестал тратить деньги впустую и защитил своих клиентов.

Как мы защищаем API

Используем позитивную модель защиты: «запрещено всё, кроме разрешённого —. блокируем любой трафик, кроме типов запросов, которые вы заранее отметили как легитимные. Это надёжнее, чем «разрешено всё, кроме запрещённого» ( негативная модель), потому что снижает шанс пропустить новый тип атаки, не указанный в старых правилах.

Простой пример: API должен принимать запросы только от вашего мобильного приложения и из офисной сети. Такие запросы попадают в «разрешённый трафик». Остальные запросы отклоняются.

Для вас мы создадим индивидуальный защитный профиль с учётом особенностей ресурса и ваших пожеланий — для этого заполните опросник (см. ниже).

Чтобы мы настроили защиту API, пройдите эти шаги

1. Подтвердите, что нужна защита API

Наши технические инженеры отправят опросник. Один из пунктов в нём — об API:

Нужно ли защищать API? Если да, то подскажите — туда обращается мобильное приложение или только человек с браузером?

В ответе укажите, что защита API нужна и что/кто к нему должен обращаться.

Мы спрашиваем, кто обращается к API, чтобы понять, закрытый он или открытый. Это поможет правильно сформировать защитный профиль:

Открытый API доступен любым клиентам из Интернета — в том числе любым ботам
Закрытый API рассчитан на узкий круг известных клиентов (ваше приложение/партнёры/офисные сети) с чёткими отличительными признаками

2. Ответьте на дополнительные вопросы

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

Для закрытого API

Запрос	Как используем эту информацию	Как ответить	Пример ответа
1. Доверенные IP/подсети	Будем пропускать запросы с этих IP-адресов без проверок	Перечислите точные IP или CIDR-подсети	192.168.10.0/24
2. Перечень актуальных версий допустимых приложений и признаков, по которым их можно отличить	Опишем «портрет» легитимного клиента, чтобы надёжнее отсекать эмуляторы	Используйте шаблон: + ОС / Имя приложения / Отличительные признаки (укажите версии, заголовки, пути, токены)	(iOS) (Актуальная версия приложения для iOS) (headers: 'User-Agent':'MyApp_v1.01', 'Level':'User'; location: '/mobile/ios'; и т. д.) (Android) (Актуальная версия приложения для Android) (headers: 'User-Agent':'MyApp_v1.01', 'Level':'User'; location: '/mobile/android'; и т. д.)
3. Партнёрские интеграции — Допустимы ли запросы не только от вашего приложения (например, от партнёров)? Какие у них отличительные признаки?	Запросы от партнёров будем пропускать без проверок либо с ограничением по rate limits	Перечислите партнёров, способы аутентификации, IP-диапазоны, обязательные заголовки, разрешённые эндпоинты и другие признаки, по которым можно отличить партнёрские запросы. Укажите ограничения по частоте.	Партнёр X — IP 203.0.113.50, авторизация по API-key, доступ к /partner/*, до 100 rps
4. Запросы из браузеров — Допускаете ли обращения к закрытому API из браузера?	Если к вашему API нельзя обращаться из браузера, заблокируем такие запросы. Если можно, пропустим те из них, которые для вас допустимы.	Укажите «да/нет». Если «да» — опишите CORS-политику, механизмы авторизации, требования к заголовкам и допустимые сценарии.	Да, допускаем. Разрешены только запросы с https://example.com, методы GET/POST, авторизация по JWT в cookie

Запрос

Как используем эту информацию

Как ответить

Пример ответа

1. Доверенные IP/подсети

Будем пропускать запросы с этих IP-адресов без проверок

Перечислите точные IP или CIDR-подсети

192.168.10.0/24

2. Перечень актуальных версий допустимых приложений и признаков, по которым их можно отличить

Опишем «портрет» легитимного клиента, чтобы надёжнее отсекать эмуляторы

Используйте шаблон: + ОС / Имя приложения / Отличительные признаки (укажите версии, заголовки, пути, токены)

(iOS) (Актуальная версия приложения для iOS) (headers: 'User-Agent':'MyApp_v1.01', 'Level':'User'; location: '/mobile/ios'; и т. д.)

(Android) (Актуальная версия приложения для Android) (headers: 'User-Agent':'MyApp_v1.01', 'Level':'User'; location: '/mobile/android'; и т. д.)

3. Партнёрские интеграции

— Допустимы ли запросы не только от вашего приложения (например, от партнёров)? Какие у них отличительные признаки?

Запросы от партнёров будем пропускать без проверок либо с ограничением по rate limits

Перечислите партнёров, способы аутентификации, IP-диапазоны, обязательные заголовки, разрешённые эндпоинты и другие признаки, по которым можно отличить партнёрские запросы. Укажите ограничения по частоте.

Партнёр X — IP 203.0.113.50, авторизация по API-key, доступ к /partner/*, до 100 rps

4. Запросы из браузеров

— Допускаете ли обращения к закрытому API из браузера?

Если к вашему API нельзя обращаться из браузера, заблокируем такие запросы. Если можно, пропустим те из них, которые для вас допустимы.

Укажите «да/нет». Если «да» — опишите CORS-политику, механизмы авторизации, требования к заголовкам и допустимые сценарии.

Да, допускаем. Разрешены только запросы с https://example.com, методы GET/POST, авторизация по JWT в cookie

Для открытого API

Вопрос	Как используем эту информацию	Как ответить	Пример ответа
1. Определение чувствительных точек входа — Какие точки входа (API endpoints) потребляют наибольшее количество ресурсов и могут считаться "тяжелыми"? — Какие точки входа могут представлять интерес для конкурентов в плане извлечения информации? — Какие точки входа используются для аутентификации и регистрации пользователей? — Есть ли другие точки входа, требующие особого внимания по каким-либо причинам?	Сосредоточим строгие проверки и лимиты там, где потенциальный ущерб максимален. Например, вход/регистрация (брутфорс/одноразовые коды), экспорт/поисковые выдачи (скрейпинг), расчёты/калькуляторы (дорогие операции), массовые отправки (почта/SMS)	Перечислите URL-пути/паттерны и кратко укажите риск для каждого	/api/v1/auth/* — чувствительные данные, высокая нагрузка /api/v1/search — ресурсоёмко /api/v1/export — массовые выгрузки
2. Требования к заголовкам запросов — Какие заголовки обязательны для всех пользователей API? + — Есть ли специфические заголовки для отдельных операций/эндпоинтов?	Обязательные заголовки позволяют формализовать «правильный» запрос и отсечь простые боты	Перечислите минимальный набор заголовков, обязательных для всех запросов, и укажите особенности для отдельных операций	Authorization: Bearer <token>, X-Client-Version, Content-Type: application/json
3. Ограничения по нагрузке — Какой уровень активности от одного пользователя/IP/агента неприемлем даже при «правильной» форме запроса?	Установим rate limits	Укажите числа по минуте/часу/суткам для ключевых эндпоинтов и в целом для API	/auth — не более 10 запросов в минуту; /search — до 100 запросов в минуту
4. Существующие меры контроля нагрузки — Какие rate-лимиты уже действуют?	Чтобы понимать, какой порог запросов допустим для вас, и блокировать превышения	Перечислите активные политики и исключения	/auth — 10 rps на токен; /search — 60 rpm на IP; исключение — админ-аккаунты

Вопрос

Как используем эту информацию

Как ответить

Пример ответа

1. Определение чувствительных точек входа

— Какие точки входа (API endpoints) потребляют наибольшее количество ресурсов и могут считаться "тяжелыми"?

— Какие точки входа могут представлять интерес для конкурентов в плане извлечения информации?

— Какие точки входа используются для аутентификации и регистрации пользователей?

— Есть ли другие точки входа, требующие особого внимания по каким-либо причинам?

Сосредоточим строгие проверки и лимиты там, где потенциальный ущерб максимален. Например, вход/регистрация (брутфорс/одноразовые коды), экспорт/поисковые выдачи (скрейпинг), расчёты/калькуляторы (дорогие операции), массовые отправки (почта/SMS)

Перечислите URL-пути/паттерны и кратко укажите риск для каждого

/api/v1/auth/* — чувствительные данные, высокая нагрузка /api/v1/search — ресурсоёмко /api/v1/export — массовые выгрузки

2. Требования к заголовкам запросов

— Какие заголовки обязательны для всех пользователей API? + — Есть ли специфические заголовки для отдельных операций/эндпоинтов?

Обязательные заголовки позволяют формализовать «правильный» запрос и отсечь простые боты

Перечислите минимальный набор заголовков, обязательных для всех запросов, и укажите особенности для отдельных операций

Authorization: Bearer <token>, X-Client-Version, Content-Type: application/json

3. Ограничения по нагрузке

— Какой уровень активности от одного пользователя/IP/агента неприемлем даже при «правильной» форме запроса?

Установим rate limits

Укажите числа по минуте/часу/суткам для ключевых эндпоинтов и в целом для API

/auth — не более 10 запросов в минуту; /search — до 100 запросов в минуту

4. Существующие меры контроля нагрузки

— Какие rate-лимиты уже действуют?

Чтобы понимать, какой порог запросов допустим для вас, и блокировать превышения

Перечислите активные политики и исключения

/auth — 10 rps на токен; /search — 60 rpm на IP; исключение — админ-аккаунты

3. Направьте трафик на наши серверы

Направьте трафик на наши серверы — и мы запустим обучение системы защиты. Обучение нужно, чтобы система адаптировалась к вашему трафику и чётко различала легитимные и подозрительные запросы.

Как проходит процесс:

Вы направляете трафик на наши серверы, мы проксируем.
По согласованию с вами подключаем временный защитный профиль — с его помощью ваш ресурс остаётся защищён во время обучения. Этот профиль использует готовые сигнатуры для большинства известных приложений, чтобы блокировать подозрительные запросы и пропускать легитимные.
Обеляем (пропускаем без проверок) трафик, который вы просили обелить в опроснике.
Запускаем обучение: собираем статистику по трафику, выявляем закономерности, пишем сигнатуры, настраиваем лимиты и готовим рекомендации. Если нужно что-то обсудить (например, наши рекомендации), связываемся с вами.
По завершении формируем индивидуальный защитный профиль.

Сколько занимает обучение. Обычно 3 рабочих дня. В отдельных случаях дольше — например, если реальный трафик не совпадает с данными из опросника.

Каков результат обучения. Создаём индивидуальный защитный профиль — набор настроек защиты, созданный под специфику вашего ресурса. Он учитывает все пожелания из опросника.

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

видны всплески нагрузки/аномалии;
стоит ужесточить требования к заголовкам;
обнаружены «похожие на легитимные» запросы, которых нет в опроснике.

4. Подтвердите включение защиты

Как только закончим обучение, инженер свяжется с вами, чтобы согласовать активацию индивидуального защитного профиля. Подтвердите её — и защита начнёт работать с учётом всех пожеланий из опросника.

Когда защита уже включена: управляйте защитным профилем

В личном кабинете вы можете настроить whitelist, blacklist, фильтрацию запросов по географическому признаку. Для Антибота вы также можете задать кастомные пользовательские правила.

Для более сложных настроек свяжитесь с персональным менеджером или нашими инженерами, мы поможем.

Остались вопросы?

Напишите нашим инженерам напрямую или отправьте имейл на support@servicepipe.ru — мы всё проясним и поможем настроить.