Побудувала ліміти запитів і захист від зловживань

Ситуація. Публічний каталог компаній і фахівців стає мішенню того самого дня, коли запускається. Скраперам потрібні дані, спам‑акаунтам — охоплення, а ендпоінтом, обслуговування якого коштує платформі реальних грошей, — пошук, експорт, усе, що звертається до зовнішнього API, — варто зловживати вже тому, що викликати його нічого не коштує. Ніхто з них не має злого наміру саме щодо цієї платформи; це просто звичайна погода у відкритому інтернеті.

Завдання. Для дорогих і вразливих до зловживань шляхів потрібні були обмеження, які витримують тиск, зокрема й тоді, коли недоступна залежність самого обмежувача.

Дія. Обмежувачів частоти запитів тут 22, і кожен налаштований під той шлях, який захищає, а не один глобальний ліміт на все, бо спроба входу, пошук і масовий експорт стають зловживанням за дуже різної частоти. Стан зберігається в Redis, тож ліміт спільний для всіх інстансів, а не окремий у кожному процесі, де його легко обійти. Найважливіше рішення — що відбувається, коли Redis недоступний: обмежувачі закриваються (fail closed). Трафік відхиляють, а не пропускають не дивлячись, — це менш зручна відповідь, зате єдина, яку можна обґрунтувати. Доповнюють їх Cloudflare Turnstile на шляхах, де варто перевіряти відвідувача, 351 рядок проміжного шару ідемпотентності, щоб повторений запис не перетворився на два, блокування за origin, що відкидає запити, які прийшли не через парадні двері, і власна перевірка відвідувачів (challenge) на самому каталозі.

Результат. Зловживати тепер дорого для зловмисника й дешево для платформи, а збій у власному сховищі обмежувача обертається відмовою, а не відчиненими дверима. Так, закриття при збої означає, що проблема з Redis стає видимою для користувачів, — це прийнято свідомо, бо інакше проблема з Redis стала б проблемою з рахунками.