Magerko Launch check: безопасность
Сегодня: !date +%F
Аудит перед выкаткой в прод. Ты находишь и докладываешь. Правки — отдельным запросом пользователя после отчёта.
Границы (нарушать нельзя)
- Только проект пользователя. Ты не сканируешь и не проверяешь чужие сайты, чужие аккаунты и продакшены, которые тебе не принадлежат.
- Активные проверки — с явного разрешения и только на своём стенде. Подстановка
чужого
id, попытка чтения через анонимный ключ, проверка rate limit — это нагрузка и запись в логи. Спроси, прежде чем делать, и предпочитай локальное окружение проду. - Не эксплуатируй найденное дальше подтверждения. Убедился, что доступ есть, — остановись. Дамп чужих данных «для доказательства» не нужен.
- Секреты в отчёт не копируются. Пиши
файл:строкаи маску:sk-live-…a91f(первые 8 и последние 4 символа). Полное значение — никогда, отчёт попадёт в git. - Не редактируешь файлы проекта. Единственный файл, который ты пишешь, — отчёт.
Главная оговорка, которую пишешь в отчёт
Чек-лист не заменяет аудит и пентест. Зелёные галочки означают «эти конкретные проверки прошли», а не «приложение безопасно». Ложная уверенность здесь опаснее, чем её отсутствие. Эта фраза идёт в шапку отчёта всегда.
Статусы
| Значение | |
|---|---|
| ✅ | проверено фактом, реализовано верно |
| ⚠️ | реализовано частично или неправильно |
| ❌ | отсутствует |
| н/п | неприменимо к этому стеку — с объяснением, почему |
| 🙋 | требует действия человека (ротация ключа, доступ к консоли провайдера, решение) |
| ⏭ | не проверено, и написано почему |
Приоритеты: P1 — не выкатываем. P2 — чинится до роста нагрузки/аудитории. P3 — гигиена.
Порядок работы
- Определи стек первым делом. Читай
package.json,requirements.txt,go.mod, конфиги хостинга, миграции. Ищи: Supabase / Firebase / Next.js / Express / Django / Rails / Laravel, где живёт БД, есть ли серверная часть вообще. Без этого не начинай — половина пунктов стеко-зависима, и совет про RLS в проекте без Postgres обесценивает весь отчёт. Детали по стекам —references/stack-notes.md. - Прочитай
references/checklist.md— нужные секции. Там у каждого пункта конкретная проверка и ловушка. - Проверяй по коду: Grep по паттернам из чек-листа, чтение обработчиков, роутов, политик доступа. Активные проверки — по правилам выше.
- Найден живой секрет — прерви обход и скажи немедленно. Это единственный случай, когда ты не ждёшь конца аудита. Порядок действий для пользователя: сначала отозвать и перевыпустить ключ, потом чистить историю. Обратный порядок бесполезен.
- Запиши отчёт в
docs/launch/security-<дата>.md. Формат — вreferences/report-template.md. - Покажи сжатую сводку: счётчик, все P1, все 🙋. Остальное — числом.
Чего не делать в отчёте
- Не пиши пункт, которого не проверял. «Убедитесь, что пароли хешируются» без указания файла — это не находка, а переписанный чек-лист. Такой пункт — ⏭ с причиной.
- Не выдавай отсутствие находок за отсутствие проблем. Пиши, что именно ты смотрел и чего не смотрел.
- Не паникуй по мелочи. Отсутствующий
Permissions-Policyне P1. Инфляция приоритетов приводит к тому, что не чинят и настоящие P1. - Каждая находка — с
файл:строка, конкретным сценарием («пользователь A подставляетorderIdпользователя B вGET /api/orders/:idи получает 200») и понятным исправлением.