Разбор инцидента: утечка данных через API без авторизации и как мы это пропустили

Типичный понедельник: алерты и недоумение

В 08:47 SIEM загорелся алертом на необычную активность к нашему customer API. 412 запросов за 15 минут с одного IP, все к эндпоинту /v1/users/profile. Никаких 429 ошибок — значит, лимиты не сработали. Первая мысль: «Опять скрипт коллеги из маркетинга».

Оказалось хуже. Эндпоинт возвращал:

1. Полные имена
3. Телефоны
5. Хеши паролей (к счастью, bcrypt)
7. Историю заказов

8. ...без какой-либо авторизации. Достаточно было знать URL.

   Как это прошло код-ревью?

   Чеклист того, что сломалось в процессе разработки:

   1. Тесты: mock-авторизация была, но проверяла только статус 200
   3. Документация: в Swagger эндпоинт помечен как «требует JWT», но код этого не проверял
   5. Мониторинг: алерты на аномальные запросы появились только после инцидента

   6. Похожий кейс был в прошлогоднем отчёте, но мы решили, что «у нас не применимо».

      Что теперь делать

      Помимо очевидного (фикс, аудит других API, рассылка уведомлений):

      • Внедрили mandatory проверку авторизации через pre-commit hook
      • Добавили в SIEM правила на ratio авторизованных/неавторизованных запросов
      • Завели CVE (да, я злюсь) на фреймворк, который молча проглатывал ошибки JWT

      • И да, маркетологи наконец получили свой отдельный эндпоинт с ограниченными данными. После трёх попыток объяснить, что «нам просто нужно всё» — не аргумент.