Як компанії захистити свої API: Практичні кроки

Цей гайд — про те, як побудувати практичну і відтворювану модель безпеки API: від інвентаризації й аутентифікації до тестування, моніторингу та реагування.

1) Інвентаризація та базова гігієна

• Повний реєстр API. Продукційні, стейджинг, внутрішні, експериментальні. Зв’яжи кожен ендпойнт з командою-власником.
• Контракти. Зберігай OpenAPI/AsyncAPI схеми в репозиторії. Увімкни перевірку схеми в CI.
• Життєвий цикл. Вказуй статус (alpha/beta/GA/deprecated) і дату EOL. Версіонуй: /v1, /v2.

2) Сильна аутентифікація та авторизація

• OAuth2/OIDC + JWT для публічних/мобільних клієнтів; mTLS або підписані ключі для сервіс-ту-сервіс.
• Scopes/permissions. Принцип найменших привілеїв, окремі токени на кожен use-case.
• Ротація та короткий TTL. Access-токени короткі, refresh-токени з ротацією.
• BOLA/BFLA-захист. Перевіряй право доступу до кожного ресурсу, а не лише роль користувача.

{
  "components": {
    "securitySchemes": {
      "oauth2": {
        "type": "oauth2",
        "flows": {
          "authorizationCode": {
            "authorizationUrl": "https://auth.example.com/oauth/authorize",
            "tokenUrl": "https://auth.example.com/oauth/token",
            "scopes": {
              "orders:read": "Read orders",
              "orders:write": "Create/modify orders"
            }
          }
        }
      }
    }
  },
  "security": [{ "oauth2": ["orders:read"] }]
}

3) Транспорт і заголовки

• TLS 1.2+ обов’язково, HSTS, заборона HTTP. Для внутрішніх — mTLS.
• CORS: дозволяй тільки довірені origin, credentials — off за замовчуванням.
• Безпечні заголовки: Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy.

4) Валідація вхідних даних та захист від ін’єкцій

• Схеми: JSON Schema/DTO-валідація перед бізнес-логікою.
• Ліміти полів: max length, allowed enums, strict types; заборона зайвих полів (масове присвоєння).
• Sanitize для HTML/SQL/LDAP/NoSQL. Параметризовані запити.

5) Ліміти, квоти, анти-аб’юз

• Rate limiting (per-IP, per-token, per-user) і burst control.
• Quotas на день/місяць, окремі для бекграунд-джобів і інтерактивних клієнтів.
• Pagination + server-side filtering — проти масового витоку (scraping).

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

6) Секрети та ключі

• Vault/KMS, жодних секретів у git або у змінних середовища без шифрування.
• Прив’язка ключів до середовищ, регулярна ротація, детальні audit logs.

7) Логи, моніторинг і виявлення загроз

• Стандартизовані логи: request id, subject (userId/clientId), scope, ресурс, результат, latency.
• Аномалії: різкий сплеск 401/403/429, незвичні гео, нетипові scopes — тригери для alerting/SIEM.
• Ідемпотентність для POST (ключ-ідемпотентності) + ретраї на клієнті.

8) Вебхуки

• Підпис повідомлень (HMAC) + timestamp, перевірка відхилення за часом.
• Retry з backoff, ідемпотентні обробники, allowlist IP або mTLS.

<?php
$payload = file_get_contents('php://input');
$ts = $_SERVER['HTTP_X_TS'] ?? '';
$sig = $_SERVER['HTTP_X_SIG'] ?? '';
$secret = getenv('WEBHOOK_SECRET');

$base = $ts . '.' . $payload;
$calc = base64_encode(hash_hmac('sha256', $base, $secret, true));

if (!hash_equals($calc, $sig) || abs(time() - (int)$ts) > 300) {
  http_response_code(401);
  exit('invalid signature');
}
echo 'ok';

9) Тестування безпеки (безперервне)

• SAST/DAST у CI, fuzzing за контрактом OpenAPI.
• Контракт-тестування провайдер ↔ споживач (Pact тощо).
• Перевірки OWASP API Top-10 (BOLA, BFLA, Excessive Data Exposure, Mass Assignment, SSRF тощо).
• Багбаунті або приватні дослідники — до/після релізу великих змін.

10) Процеси інцидент-респонсу

• Runbook для витоків ключів, компрометації токенів, масового brute-force.
• Кнопка «kill-switch»: відкликання ключів/токенів, блок локацій/клієнтів, зниження лімітів.
• Комунікаційний план для клієнтів та регуляторні зобов’язання.

Швидкий чекліст перед релізом

• ✅ OpenAPI схема оновлена та валідована в CI
• ✅ OAuth2/OIDC або mTLS, короткоживучі токени, ротація
• ✅ Перевірки авторизації на рівні ресурсу (BOLA)
• ✅ Валідація даних, заборона зайвих полів
• ✅ Rate limiting + квоти, CORS лише для trusted origin
• ✅ Секрети у Vault/KMS, ротація ключів
• ✅ Логи з request id, алерти за аномаліями
• ✅ Вебхуки підписані, ідемпотентні
• ✅ SAST/DAST/fuzz у CI, перевірка OWASP API Top-10
• ✅ Runbook інцидентів та «kill-switch» перевірені

Захист API — це не одноразовий аудит, а дисципліна. Почни з базових контролів, автоматизуй перевірки в CI/CD і підтримуй прозорість: чіткі контракти, логи та відповідальні власники сервісів.