Як захистити API чи веб-застосунок

Коротка відповідь: Віддавайте все через HTTPS, автентифікуйте короткоживучими токенами чи ключами, обмежуйте частоту на кожному ендпоінті на веб-сервері (limit_req в Nginx), валідуйте весь ввід, ховайте адмін-маршрути від публічного інтернету й логуйте достатньо, щоб помічати зловживання. Більшість зламів застосунків експлуатують відсутні основи, а не екзотичні діри.

Огляд

API та веб-застосунки атакують інакше, ніж сервери: credential stuffing, витік токенів, ін’єкції, скрейпінг і флуди Layer 7 приходять як «валідний» HTTP. Тому захист живе у веб-сервері й на рівні застосунку — сам фаєрвол не відрізнить спробу входу від атаки.

Що потрібно мати

• Перелік публічних ендпоінтів і розуміння, які з них змінюють дані чи коштують реальних ресурсів.
• Уже налаштований TLS (інструкція з SSL-сертифікатів).

Покрокова інструкція

1. Ліміт частоти в Nginx:

   limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
   server {
       location /api/ { limit_req zone=api burst=20 nodelay; }
       location /login { limit_req zone=api burst=5; }
   }

2. Гігієна автентифікації: короткоживучі токени, ротація API-ключів, ніяких облікових даних по HTTP, хеші паролів через bcrypt/argon2.
3. Валідація вводу: параметризований SQL всюди, строгі схеми для JSON-тіл, ліміти розміру (client_max_body_size).
4. Зменшення експозиції: прив’язуйте адмін-панелі й бази до localhost чи VPN; фаєрвол має показувати лише 80/443 та SSH.
5. Розгляньте WAF: ModSecurity з OWASP Core Rule Set для самостійного фільтрування типових ін’єкційних патернів.
6. Логуйте й алертуйте: сплески 4xx/5xx, невдалі автентифікації та нові user-agent; зловживання, помічене за годину, коштує менше, ніж помічене за місяць.

Типові проблеми

• Занадто жорсткі ліміти: легітимні клієнти отримують 503 — виводьте пороги зі спостережуваного трафіку із запасом і використовуйте burst.
• Довіра до клієнтських перевірок: валідація має відбуватися на сервері; клієнт контролюється атакувальником.
• Секрети в репозиторії: токени, закомічені в історію git, лишаються витеклими назавжди — ротуйте і використовуйте змінні середовища.

Коли звертатися в підтримку

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

Часті запитання

Що додати до публічного API першим?

Обмеження частоти на рівні веб-сервера — Nginx limit_req з per-IP зоною зупиняє credential stuffing, скрейпінг і випадкові цикли клієнтів ще до вашого коду застосунку.

Чи потрібен WAF маленькому застосунку?

Це корисний додатковий шар: ModSecurity з OWASP Core Rule Set безкоштовно фільтрує типові патерни ін’єкцій і сканерів, хоча ніколи не замінює валідацію вводу в коді.

Як поводитися з API-ключами й токенами?

Видавайте короткоживучі токени, де можливо, ротуйте довгоживучі ключі за розкладом, передавайте їх лише по HTTPS і тримайте у змінних середовища — ніколи в git-репозиторії.

Схожі статті

• Як захиститися від brute-force атак
• Як налаштувати SSL-сертифікати
• Як виявити підозрілий трафік
• Що таке DDoS-атака?

Потрібна допомога? Звернутися в підтримку Cloud2Y →