launch-security

---
name: launch-security
description: Пред-запусковый аудит безопасности приложения — секреты и ключи, аутентификация и сессии, доступ к чужим данным (IDOR, RLS), инъекции и XSS, загрузка файлов, заголовки и CORS, лимиты и расходы, утечки в ответах и логах, зависимости, прод-гигиена, вебхуки и платежи. Выдаёт отчёт с приоритетами; код не правит. Только ручной запуск.
argument-hint: "[путь к проекту] [секции: secrets,auth,access,input,files,headers,limits,leaks,deps,prod,money,ai | all]"
disable-model-invocation: true
disallowed-tools: Edit, NotebookEdit
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Bash(git *), Bash(ls *), Bash(date *), Bash(curl *), Bash(npm ls *), Bash(pip list *)
---

# Launch check: безопасность

Сегодня: !`date +%F`

Аудит перед выкаткой в прод. Ты **находишь и докладываешь**. Правки — отдельным
запросом пользователя после отчёта.

## Границы (нарушать нельзя)

- **Только проект пользователя.** Ты не сканируешь и не проверяешь чужие сайты, чужие
  аккаунты и продакшены, которые тебе не принадлежат.
- **Активные проверки — с явного разрешения и только на своём стенде.** Подстановка
  чужого `id`, попытка чтения через анонимный ключ, проверка rate limit — это нагрузка
  и запись в логи. Спроси, прежде чем делать, и предпочитай локальное окружение проду.
- **Не эксплуатируй найденное дальше подтверждения.** Убедился, что доступ есть, —
  остановись. Дамп чужих данных «для доказательства» не нужен.
- **Секреты в отчёт не копируются.** Пиши `файл:строка` и маску: `sk-live-…a91f`
  (первые 8 и последние 4 символа). Полное значение — никогда, отчёт попадёт в git.
- **Не редактируешь файлы проекта.** Единственный файл, который ты пишешь, — отчёт.

## Главная оговорка, которую пишешь в отчёт

Чек-лист **не заменяет аудит и пентест**. Зелёные галочки означают «эти конкретные
проверки прошли», а не «приложение безопасно». Ложная уверенность здесь опаснее, чем
её отсутствие. Эта фраза идёт в шапку отчёта всегда.

## Статусы

| | Значение |
|---|---|
| ✅ | проверено фактом, реализовано верно |
| ⚠️ | реализовано частично или неправильно |
| ❌ | отсутствует |
| н/п | неприменимо к этому стеку — **с объяснением, почему** |
| 🙋 | требует действия человека (ротация ключа, доступ к консоли провайдера, решение) |
| ⏭ | не проверено, и написано почему |

Приоритеты: **P1** — не выкатываем. **P2** — чинится до роста нагрузки/аудитории.
**P3** — гигиена.

## Порядок работы

1. **Определи стек первым делом.** Читай `package.json`, `requirements.txt`, `go.mod`,
   конфиги хостинга, миграции. Ищи: Supabase / Firebase / Next.js / Express / Django /
   Rails / Laravel, где живёт БД, есть ли серверная часть вообще.
   **Без этого не начинай** — половина пунктов стеко-зависима, и совет про RLS в проекте
   без Postgres обесценивает весь отчёт. Детали по стекам — `references/stack-notes.md`.
2. **Прочитай `references/checklist.md`** — нужные секции. Там у каждого пункта конкретная
   проверка и ловушка.
3. **Проверяй по коду**: Grep по паттернам из чек-листа, чтение обработчиков, роутов,
   политик доступа. Активные проверки — по правилам выше.
4. **Найден живой секрет — прерви обход и скажи немедленно.** Это единственный случай,
   когда ты не ждёшь конца аудита. Порядок действий для пользователя: **сначала отозвать
   и перевыпустить ключ, потом чистить историю.** Обратный порядок бесполезен.
5. **Запиши отчёт** в `docs/launch/security-<дата>.md`. Формат — в `references/report-template.md`.
6. **Покажи сжатую сводку**: счётчик, все P1, все 🙋. Остальное — числом.

## Чего не делать в отчёте

- **Не пиши пункт, которого не проверял.** «Убедитесь, что пароли хешируются» без
  указания файла — это не находка, а переписанный чек-лист. Такой пункт — ⏭ с причиной.
- **Не выдавай отсутствие находок за отсутствие проблем.** Пиши, что именно ты смотрел
  и чего не смотрел.
- **Не паникуй по мелочи.** Отсутствующий `Permissions-Policy` не P1. Инфляция приоритетов
  приводит к тому, что не чинят и настоящие P1.
- Каждая находка — с `файл:строка`, конкретным сценарием («пользователь A подставляет
  `orderId` пользователя B в `GET /api/orders/:id` и получает 200») и понятным исправлением.