Безпека API на edge: захист REST і GraphQL від зловживань
API не має «фасаду», за яким можна сховатися
Вебсторінка має форму, кнопки, JavaScript — цілий шар, крізь який мусить продертися бот. API не має нічого з цього. Це прямий, документований, машиночитний вхід у ваш застосунок. Саме те, що робить його зручним для ваших клієнтів, робить його зручним і для зловмисника: жодних кроків, жодної двозначності, лише кінцева точка й дані.
Для команд, які винесли логіку в бекенд і роздають мобільний застосунок чи SPA поверх API, це означає, що більшість реального трафіку — і більшість атак — тепер ходить не по HTML, а по JSON. WAF, налаштований на захист сторінок, цього шару майже не бачить.
Типові зловживання, специфічні для API
- Перебір і енумерація.
/users/1,/users/2,/users/3— послідовний обхід ідентифікаторів, щоб вивудити чужі записи. Кожен окремий запит виглядає валідним; шкідлива тут саме послідовність. - Зловживання частотою. Кінцева точка входу чи пошуку, яку довбають тисячами запитів, — це або credential stuffing, або спроба покласти origin. Про це — окрема стаття про rate limiting.
- Ін’єкції в тілі запиту. SQL-ін’єкції та впровадження команд однаково приходять і в JSON-полі, і в параметрі форми. Набір правил OWASP перевіряє тіло запиту, а не лише URL.
- Специфіка GraphQL. Одна кінцева точка, довільної складності запити. Глибоко вкладений запит або зловживання інтроспекцією схеми здатні змусити сервер зробити величезну роботу з одного невеликого HTTP-запиту — класичний вектор відмови в обслуговуванні.
Що дає фільтрація саме на edge
Ключова ідея: рішення про запит ухвалюється до того, як він торкнеться вашого коду й вашої бази. На нашому вузлі в ЄС кожен запит до API проходить той самий конвеєр, що й звичайний вебтрафік:
- Розбір і нормалізація. Запит розкладається на метод, шлях, заголовки й тіло — щоб правила бачили реальний вміст, а не обфусковану обгортку.
- Сигнатурна перевірка. Два сигнатурних WAF-рушії (один в ізольованій пісочниці, один нативний) застосовують набір правил OWASP до тіла й параметрів, ловлячи класичні класи ін’єкцій незалежно від того, чи це форма, чи JSON.
- Обмеження частоти й поведінки. Перебір ідентифікаторів і сплески на чутливих кінцевих точках гасяться лічильниками, які працюють спершу в памʼяті вузла, а потім у спільному сховищі між вузлами.
- Драбина замість глухої стіни. Підозрілий, але не однозначно шкідливий клієнт проходить сходинки перевірки, а не отримує сліпий бан, що поламав би легітимну інтеграцію.
Практика для команди, що віддає API назовні
Кілька речей, які варто зробити незалежно від того, який edge ви оберете:
- Розділяйте публічні й приватні кінцеві точки. Те, що ходить лише з вашого мобільного застосунку, не мусить бути так само відкритим, як публічний ендпоінт документації.
- Ставте ліміти на дорогі операції. Пошук, експорт, генерація звітів — усе, що коштує origin реальних ресурсів, має жорсткіший ліміт, ніж дешеве читання.
- Обмежуйте складність GraphQL. Глибина й кількість полів у запиті — це вхідні дані, і їх треба валідувати, як будь-які інші.
- Дивіться в аудит-лог. Кожне рішення на edge фіксується незмінним записом із прив’язкою до тенанта — це ваша основна видимість того, що відбувається з API.
Чого ми не обіцяємо
Edge-фільтр не замінює авторизацію й перевірку прав усередині застосунку — він її доповнює. Ми не «робимо ваш API безпечним» одним перемикачем; ми знімаємо з нього масовий шум, автоматизовані зловживання й відомі класи ін’єкцій, щоб ваш код мав справу з меншим і чистішим потоком. Накладні витрати на цю фільтрацію тримаємо в межах проєктного бюджету затримки — як саме ми його вимірюємо, описано в методології.
Хочете поставити фільтр перед своїм API, не переписуючи бекенд? Напишіть нам.