раздел 11 · рецепт

Security-аудит

Security-аудит - то, что должно происходить минимум перед каждым крупным релизом и при каждой смене авторизации/работы с деньгами/работы с PII. С Claude Code это не страшный многонедельный процесс, а одна команда /security-review + час осознанной работы.

Когда применять

  • Перед публичным запуском продукта
  • После добавления авторизации или работы с платежами
  • Когда подключаете новую внешнюю интеграцию
  • После того, как PII (имена, телефоны, документы) появились в системе
  • Раз в квартал на действующем продукте

Шаги

Шаг 1. Автоматический security-review

В Claude Code:
/security-review

Что делает:
- Просматривает текущие изменения (diff с main)
- Проверяет паттерны OWASP top 10
- Ищет хардкод секретов
- Анализирует контекст: где входная точка, какие данные принимаются
- Возвращает приоритизированный отчёт с severity

Это первый проход. Берите топ-priority находки, остальные - на ревью человеком.

Шаг 2. OWASP top 10 - ручной чек-лист

Запустите для каждого пункта:

Промпт:
"Проверь код на OWASP A01:2021 - Broken Access Control.
Найди все endpoints, ищи:
- Где роль/owner проверяется в начале, а не в конце
- Где user_id берётся из request body вместо JWT
- IDOR - где id запрашиваемого ресурса не сверяется с owner
- Privilege escalation - где роль меняется без проверки текущей
Верни таблицу endpoint:уязвимость:как исправить."

Повторите для:

| OWASP | Что искать | |---|---| | A01 Broken Access Control | IDOR, отсутствие проверки роли, privilege escalation | | A02 Cryptographic Failures | Слабые алгоритмы (MD5, SHA1), хранение паролей в plain | | A03 Injection | SQL/NoSQL/Command injection, XSS, template injection | | A04 Insecure Design | Отсутствие rate limiting, captcha, валидации | | A05 Security Misconfiguration | Default credentials, debug-режим в проде, открытый /admin | | A06 Vulnerable Components | Устаревшие зависимости с известными CVE | | A07 Identification & Authentication | Слабые пароли, отсутствие 2FA, session fixation | | A08 Software & Data Integrity | Unsigned обновления, eval() с user-input | | A09 Security Logging Failures | Нет логирования критических событий (login, payment) | | A10 SSRF | Запрос на user-controlled URL без whitelisting |

Шаг 3. Поиск утечек секретов

# Поиск секретов в git-истории
pip install gitleaks
gitleaks detect --source . --verbose

# Или через Claude

Промпт:
"Просканируй весь репозиторий на наличие хардкод-секретов:
- API-ключи (паттерны: AIza..., sk-..., AKIA..., AAAA...)
- Пароли в коде ("password": "...")
- Приватные ключи (-----BEGIN PRIVATE KEY-----)
- Connection strings с паролем
Используй grep и регулярки. Включи .git/ историю.
Не репортуй примеры в .env.example и тестовые фикстуры."

Шаг 4. Аудит зависимостей

# Node
pnpm audit
npm audit --audit-level=moderate

# Python
pip-audit
safety check

# Universal
trivy fs .

Шаг 5. Headers и CORS

Промпт:
"Проверь HTTP-headers нашего API:
- Strict-Transport-Security есть?
- X-Frame-Options или Content-Security-Policy?
- X-Content-Type-Options: nosniff?
- Referrer-Policy?
CORS:
- Allow-Origin не *, если cookies?
- Allow-Credentials с осознанием рисков?
- Whitelist origins, не regex .* ?
Покажи curl-команду для проверки и предложи middleware."

Шаг 6. Финальный отчёт

После всех проходов:

Промпт:
"Сведи все findings в один отчёт:
- Критические (фиксить до релиза)
- Высокие (фиксить в этом спринте)
- Средние (план на квартал)
- Низкие (бэклог)
Для каждого: что, где, как эксплуатировать, как фиксить.
Формат: Markdown, можно отправить команде."

Антипаттерны

| Что не делать | Почему | |---|---| | Аудит только перед прод-релизом | Безопасность - не финальный чек, она в каждом PR. | | Игнорировать «low severity» | Несколько low может комбинироваться в high. | | Удалять console.log как «security fix» | Утечка через логи - это другая проблема. | | Менять секрет, но не ротировать его на проде | Хакер уже знает старый, он работает. | | Доверять «AI-сгенерированный fix» без ревью | Иногда Claude добавляет уязвимости, фиксируя другие. |

Полезные ссылки