Захист бекенду: налаштування Rate Limiting через API Gateway

Уявіть: запускаєте промо-акцію, і ваш бекенд лягає під шквалом запитів. При піковому навантаженні 10 000 rps in-app rate limiting не встигає синхронізуватися між сервісами — кожен мікросервіс зберігає свій лічильник, і burst призводить до перевищення лімітів на 200%. Централізоване обмеження запитів через API Gateway — єдина точка контролю, де політики доступу застосовуються до всього трафіку, не вимагаючи змін бізнес-логіки. Ми проводили аудит для клієнта з fintech: після впровадження Kong rate limiting кількість 429 помилок знизилася на 90%, а навантаження на бекенд — на 70%.

Чому API Gateway, а не in-app rate limiting?

In-app рішення вимагає змін у кожному сервісі, дублювання коду та координації. Gateway же — один шар, де політики застосовуються однаково. Не потрібно чіпати бізнес-логіку: достатньо налаштувати плагін. Плюс — єдиний моніторинг, логування та можливість змінювати ліміти на льоту без деплоїв. За оцінками, Gateway rate limiting працює в 5 разів швидше ніж in-app рішення за рахунок апаратного прискорення.

Порівняння підходів:

Який алгоритм rate limiting обрати?

Алгоритмів декілька, і вибір залежить від профілю навантаження.

Як налаштувати rate limiting на конкретних Gateway?

Налаштування в Kong

Kong підтримує багаторівневі ліміти: глобальний, на сервіс, на consumer. Використовуємо Redis для синхронізації. Приклад налаштування через Admin API:

# Глобальний ліміт (всі сервіси) — 1000 запитів на хвилину
curl -X POST http://localhost:8001/plugins \
  -d "name=rate-limiting" \
  -d "config.minute=1000" \
  -d "config.hour=20000" \
  -d "config.policy=redis" \
  -d "config.redis_host=redis" \
  -d "config.limit_by=ip"

# Ліміт на рівні сервісу payments-api — 10 rps
curl -X POST http://localhost:8001/services/payments-api/plugins \
  -d "name=rate-limiting" \
  -d "config.second=10" \
  -d "config.minute=200" \
  -d "config.limit_by=consumer"

# Ліміт для consumer free-tier — 60 запитів на хвилину
curl -X POST http://localhost:8001/consumers/free-tier/plugins \
  -d "name=rate-limiting" \
  -d "config.minute=60" \
  -d "config.hour=500"

Заголовки у відповіді містять інформацію про ліміти та час скидання. Офіційна документація: Kong Rate Limiting.

Налаштування в APISIX

APISIX надає три плагіни: limit-count (лічильник), limit-req (leaky bucket), limit-conn (одночасні з'єднання). Приклад конфігурації через Admin API:

{
  "plugins": {
    "limit-count": {
      "count": 100,
      "time_window": 60,
      "rejected_code": 429,
      "rejected_msg": "Too many requests",
      "key": "consumer_name",
      "policy": "redis",
      "redis_host": "redis",
      "redis_port": 6379,
      "redis_database": 0,
      "show_limit_quota_header": true
    },
    "limit-req": {
      "rate": 10,
      "burst": 5,
      "key": "remote_addr",
      "rejected_code": 429
    },
    "limit-conn": {
      "conn": 50,
      "burst": 10,
      "key": "remote_addr",
      "rejected_code": 503
    }
  }
}

limit-req реалізує Leaky Bucket — запити понад rate потрапляють у чергу burst, потім 429. limit-conn обмежує кількість одночасних з'єднань.

Налаштування в AWS API Gateway

AWS використовує Usage Plans з throttle та quota. Приклад Terraform-конфігурації для чотирьох тарифних планів:

resource "aws_api_gateway_usage_plan" "tiers" {
  for_each = {
    free    = { rate = 10,  burst = 5,   quota = 1000,   period = "DAY" }
    basic   = { rate = 50,  burst = 25,  quota = 10000,  period = "DAY" }
    pro     = { rate = 200, burst = 100, quota = 100000, period = "DAY" }
    enterprise = { rate = 1000, burst = 500, quota = 0, period = "DAY" }
  }

  name = "plan-${each.key}"

  api_stages {
    api_id = aws_api_gateway_rest_api.main.id
    stage  = "prod"
  }

  throttle_settings {
    rate_limit  = each.value.rate
    burst_limit = each.value.burst
  }

  dynamic "quota_settings" {
    for_each = each.value.quota > 0 ? [1] : []
    content {
      limit  = each.value.quota
      period = each.value.period
    }
  }
}

Динамічний rate limiting за бізнес-атрибутами

Rate limit не завжди залежить тільки від IP або API-ключа. Часто потрібна логіка: підписка користувача, тип ресурсу, час доби. Приклад кастомного плагіна для Kong, який запитує ліміти з billing-сервісу:

local function get_rate_limit(consumer_id)
  local cache_key = "rate:" .. consumer_id
  local cached = kong.cache:get(cache_key)
  if cached then return cached end

  -- Запит до billing service
  local client = httpc.new()
  local res = client:request_uri("http://billing-service/limits/" .. consumer_id)
  local limits = cjson.decode(res.body)

  kong.cache:set(cache_key, limits, 300)  -- кеш 5 хвилин
  return limits
end

local limits = get_rate_limit(consumer_id)
-- limits = { minute: 1000, hour: 10000 }

Часті помилки та як їх уникнути

• Не налаштований burst — навіть легітимні сплески відхиляються. Рекомендується встановлювати burst рівним 50-100% від rate.
• Відсутній whitelist для внутрішніх сервісів — падає моніторинг. Використовуйте ip-restriction плагін з мережевими діапазонами.
• Використовується Fixed Window без урахування границі вікна — навантаження на стику вікон подвоюється. Застосовуйте Sliding Window або Leaky Bucket.
• Не налаштований заголовок Retry-After — клієнти не знають, коли повторити запит. Завжди передавайте Retry-After у відповіді 429.
• Redis без реплікації — при падінні Redis ліміти скидаються. Використовуйте кластер Redis або налаштуйте replica.

Що входить у роботу з впровадження rate limiting

1. Аудит поточної архітектури API та вибір оптимального Gateway.
2. Проектування політик: глобальні, за сервісами, за користувачами.
3. Налаштування Redis для синхронізації (якщо потрібно).
4. Інтеграція з моніторингом (Prometheus, Grafana) для візуалізації лімітів.
5. Документація схеми rate limiting для команди розробки.
6. Навчання інженерів (2-3 години воркшопу).
7. Гарантія SLA 99.9% на час експлуатації.

Базова настройка багаторівневого rate limiting (за IP, consumer, сервісом) з Redis — від 2 до 5 робочих днів залежно від складності інтеграції. Вартість базового налаштування — від $1000. Точну вартість розраховуємо після аудиту вашої архітектури — оцінка проекту безкоштовна. Ми реалізували понад 50 проектів з API Gateway для клієнтів з fintech, e-commerce та SaaS, тому гарантуємо надійне рішення під ключ.

Замовте послугу прямо зараз

Зв'яжіться з нами для консультації — ми підберемо оптимальну стратегію rate limiting під ваше навантаження. Отримайте захист бекенду за 2-5 днів.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.

HTTPS та правильна конфігурація TLS

HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.

В конфігурації Nginx/Apache перевіряємо:

• Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
• Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security з includeSubDomains; preload) — браузер більше не робить незахищених запитів
• OCSP Stapling — прискорює перевірку відкликання сертифіката
• Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.

Content Security Policy: як він закриває XSS на 99%?

CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.

Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.

Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.

'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому XSS залишається найпоширенішою вразливістю?

XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:

Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

CSRF: захист форм та API

CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.

CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.

SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.

API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.

WAF та захист від DDoS

WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:

• Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
• AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.

DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).

Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).

Інші обов'язкові заходи

Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).

SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.

Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.

Як ми працюємо?

1. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
2. Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
3. Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
4. Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
5. Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.

Що входить в роботу?

• Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
• Готова конфігурація TLS (Nginx/Apache)
• Політика CSP з режимом Report-Only та бойовою версією
• Налаштування WAF та Rate Limiting
• План оновлень залежностей
• Доступи до інструментів моніторингу (Sentry, Datadog)
• 30 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.