Чеклист безопасности AI-кода: 20 пунктов перед деплоем

AI-ассистенты генерируют код быстро, но не всегда безопасно. Модель оптимизирует на "работает", а не на "безопасно". Hardcoded API-ключи, отсутствие валидации, SQL-инъекции в сгенерированных запросах, CORS с wildcard — это реальные проблемы, которые встречаются в AI-сгенерированном коде. Не потому что AI плохой, а потому что безопасность — это отдельная экспертиза, которую нужно запрашивать явно.

Этот чеклист — 20 конкретных пунктов, которые нужно проверить перед каждым деплоем. Распечатайте его, добавьте в CLAUDE.md вашего проекта, сделайте обязательным шагом в CI/CD. Каждый пропущенный пункт — потенциальная уязвимость.

1. Нет hardcoded секретов в коде

Проверьте: API-ключи, токены, пароли, connection strings — всё должно быть в .env файлах или секретных переменных CI/CD. Ни одного секрета в исходном коде. Используйте git-secrets или truffleHog для автоматического сканирования. Если секрет когда-либо попал в git history — считайте его скомпрометированным и ротируйте.

2. .env файлы в .gitignore

Проверьте .gitignore: .env, .env.local, .env.production — все варианты должны быть исключены. Создайте .env.example с пустыми значениями для документации. Никогда не коммитьте .env.example с реальными значениями — даже "тестовыми".

3. Минимальные права для API-ключей

Каждый API-ключ должен иметь минимально необходимые права. Google Service Account — только те API, которые нужны. Supabase — anon key на клиенте, service_role только на сервере. AWS IAM — policy с конкретными действиями, не AdministratorAccess.

4. Все пользовательские данные валидируются на сервере

Клиентская валидация — для UX, серверная — для безопасности. Используйте Zod или Joi для определения схемы данных. Каждый API-эндпоинт и Server Action должен валидировать все входные данные. Никогда не доверяйте данным от клиента — даже если фронтенд "правильный", API можно вызвать напрямую.

5. Защита от SQL-инъекций

Используйте параметризованные запросы (prepared statements) — никогда не конкатенируйте пользовательский ввод в SQL-строку. Prisma, Drizzle и другие ORM делают это автоматически. Если пишете raw SQL — используйте $1, $2 плейсхолдеры. AI иногда генерирует string interpolation в SQL — это критическая уязвимость.

6. Защита от XSS

React и Next.js экранируют HTML по умолчанию — но только если вы не используете dangerouslySetInnerHTML. Если используете — санитизируйте через DOMPurify. Проверьте все места, где пользовательский контент отображается на странице: комментарии, профили, описания. Один пропущенный XSS — и злоумышленник крадёт сессии.

7. Защита от CSRF

Next.js Server Actions имеют встроенную CSRF-защиту через origin check. Для API Routes — добавьте проверку заголовка Origin или используйте CSRF-токены. Для форм — убедитесь, что форма отправляется только с вашего домена.

8. Пароли хешируются через bcrypt/argon2

Никогда не храните пароли в открытом виде. Используйте bcrypt с cost factor 12+ или Argon2id. Если используете Supabase Auth или NextAuth — они хешируют автоматически. Если кастомная авторизация — проверьте дважды.

9. JWT-токены с коротким TTL

Access token: 15 минут максимум. Refresh token: 7 дней. Никогда не храните JWT в localStorage — используйте httpOnly cookies. Проверяйте подпись токена на каждом запросе. Секрет для подписи JWT — минимум 256 бит, сгенерированный криптографически.

10. Авторизация на уровне ресурсов

Недостаточно проверить "пользователь авторизован". Нужно проверить "этот пользователь имеет право на этот ресурс". IDOR (Insecure Direct Object Reference) — одна из самых частых уязвимостей: пользователь меняет ID в URL и получает доступ к чужим данным. В каждом API-запросе проверяйте: принадлежит ли запрошенный ресурс текущему пользователю.

11. HTTPS обязателен

Весь трафик — только через HTTPS. Vercel, Cloudflare, Railway делают это автоматически. Если VPS — настройте SSL через Let's Encrypt с автообновлением. Добавьте Strict-Transport-Security заголовок для принудительного HTTPS.

12. CORS настроен корректно

Никогда Access-Control-Allow-Origin: *. Укажите конкретные домены. Для API, которые вызываются только с вашего фронтенда — разрешите только ваш домен. Для публичных API — ограничьте методы и заголовки.

13. Content Security Policy (CSP)

CSP заголовок ограничивает, откуда можно загружать скрипты, стили, изображения. Минимальная CSP: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'. Это блокирует инъекцию сторонних скриптов — основной вектор XSS-атак. Next.js поддерживает CSP через middleware или next.config.js headers.

14. Rate Limiting на API

Без rate limiting ваш API можно задосить или использовать для brute-force. Минимум: 100 запросов в минуту на IP для публичных эндпоинтов, 10 попыток входа в минуту. Используйте upstash/ratelimit или express-rate-limit. Для Next.js — middleware с Redis.

15. Ошибки не раскрывают внутренности

В продакшене: пользователь видит "Произошла ошибка", а не stack trace с путями к файлам и SQL-запросами. Настройте кастомную страницу ошибки (error.tsx в Next.js). Детальные ошибки — только в логах, недоступных пользователю.

16. Логирование без секретов

Логируйте: кто (user_id), что (action), когда (timestamp), результат (success/error). Не логируйте: пароли, токены, номера карт, полные тела запросов с чувствительными данными. Маскируйте чувствительные поля: email → a***@gmail.com, token → sk-...xxxx.

17. Аудит npm-зависимостей

Выполните npm audit перед каждым деплоем. Критические уязвимости — исправляйте немедленно. Используйте npm audit --production для проверки только продакшен-зависимостей. Настройте Dependabot или Renovate для автоматического обновления зависимостей.

18. Docker-образ без лишнего

Если используете Docker: multi-stage build, Alpine-образ, не копируйте node_modules из хоста (ставьте внутри контейнера), не запускайте от root (USER node). Не включайте .env, .git, tests в финальный образ — используйте .dockerignore.

19. Бэкапы базы данных

Автоматические бэкапы: ежедневно для PostgreSQL (pg_dump), еженедельно полный бэкап. Тестируйте восстановление из бэкапа хотя бы раз в месяц. Supabase делает бэкапы автоматически на платных планах. Для self-hosted — настройте cron + pg_dump + S3.

20. Мониторинг и алерты

Подключите мониторинг: Sentry для ошибок, UptimeRobot для доступности, логи для аномалий. Настройте алерты: 5xx ошибки больше порога, всплеск трафика (возможная DDoS), неудачные попытки входа (brute-force), изменения в критических файлах (tampering).

P0 — исправить до деплоя, без исключений. Утечка секретов или SQL-инъекция — это инцидент безопасности с первого дня. P1 — исправить в первую неделю. P2 — в первый месяц. P3 — настроить по мере развития проекта.

• Добавьте 20 пунктов в CLAUDE.md проекта — AI будет проверять автоматически
• Создайте skill /security-check, который прогоняет все пункты по коду
• Включите npm audit в CI/CD pipeline (GitHub Actions)
• Проводите ручную проверку раз в месяц — чеклист как основа, но не замена пентесту
• При каждом новом AI-сгенерированном эндпоинте — проверьте пункты 4-7 и 10

Безопасность — это не одноразовое действие, а привычка. Каждый коммит, каждый деплой, каждый новый эндпоинт — это момент, когда нужно пройтись по чеклисту. AI ускоряет разработку, но ответственность за безопасность остаётся за вами. 20 пунктов, 15 минут — и вы значительно снижаете риск инцидента.