security-check

---
name: security-check
description: "Audits the security of your own site or web app before release in terms a non-technical owner understands. Checks secrets in git history, keys in code and client bundles, database access (RLS rules and role grants), server-side permission checks, rate limits, forms and XSS, security headers, webhooks and dependencies, and explains each finding in plain words. Full report first, fixes only after the owner says yes. On a leaked key: stop, report, rotate the key, search for similar leaks. Includes a script that finds key-like strings. Triggers: 'security audit', 'check for vulnerabilities', 'leaked API key', 'pre-deploy security check', 'is it safe to deploy'. Triggers (RU): «проверь безопасность», «аудит безопасности», «проверь сайт на дыры», «нет ли утечек ключей», «можно выкатывать с точки зрения безопасности», «ключ утёк»."
---

# Аудит безопасности перед выкатом

> Instructions are in Russian. Respond in the user's language.

## Зачем

Сайт, собранный с помощью агента, работает, но агент легко оставляет за
собой открытую дверь: ключ в коде страницы, базу, которую может читать
любой, форму без лимита, через которую льют спам. Владелец кода не читает
и сам этого не заметит. Скилл проходит фиксированный список проверок,
объясняет каждую находку человеческими словами и ничего не чинит без
согласия.

Это защитная проверка **своего** проекта. Чужие сайты не сканируем и
способы взлома не расписываем.

## На чём работает

| Что | Зачем здесь |
|---|---|
| Supabase или другая база | главная зона риска: правила RLS на каждой таблице; если у агента подключён инструмент Supabase, отчёт безопасности берут у него, а не только по миграциям |
| `.env` локально и переменные хостинга (Vercel или свой сервер) | где живут ключи; в git только `.env.example` с заглушками |
| История git | удалённый из кода ключ остаётся в старых коммитах, проверка идёт по всей истории |
| `scripts/scan_secrets.py` | ищет похожие на ключи строки в файлах и истории, печатает с маской |
| Серверная функция для форм и ботов | токены только там: в одном проекте токен бота утёк из кода страницы, заявки после этого вынесли в отдельную функцию, бота пересоздали |
| Cloudflare или конфиг nginx | заголовки безопасности и редиректы, если сайт на своём сервере |
| Агент и владелец | агент проверяет и пишет отчёт, исправления только после «да» владельца |

## Когда включать

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

Статичная страница-визитка без форм и базы: достаточно пунктов 1, 2 и 8.

## Главное правило: сначала отчёт, исправления после «да»

1. **Этап 1, аудит.** Пройти весь список, по каждому пункту записать: есть
   проблема, нет, не применимо. Файл и строка, насколько опасно. Показать
   отчёт целиком. Не менять ни одной строки.
2. **Этап 2, исправления.** Только после того, как владелец прочитал отчёт
   и сказал, что чинить. Каждое исправление маленькое и точечное, без
   переделки всего вокруг.

Даже если попросили «проверь и почини» одной фразой, сначала отчёт.
Исключение одно: владелец прямо сказал «отчёт не нужен, сразу чини».

Почему так: исправление безопасности может сломать вход, оплату или
заявки. Владелец должен понимать, что меняется, до того как оно поменялось.

## Шаг 0. Понять, что перед нами

Пара минут, не отдельный раздел отчёта:

- На чём сайт: файл `package.json` (Node, Next.js и похожие),
  `requirements.txt` или `pyproject.toml` (Python), или просто HTML.
- Есть ли база и какая: Supabase, Postgres, Firebase, другая.
- Как люди входят: пароль, вход через Google или Telegram, ссылка на почту,
  входа нет вовсе.
- Где живёт сайт: хостинг вроде Vercel или Netlify, свой сервер. От этого
  зависит, где смотреть заголовки и лимиты.

Пункт не подходит к проекту: честно писать «не применимо» и почему, одной
строкой. Не натягивать.

## Проверки

### 1. Секреты в истории git

Ключ, который однажды попал в коммит и потом был удалён, всё равно лежит в
истории. Любой, у кого есть копия репозитория, его достанет.

```
python3 scripts/scan_secrets.py .
```

Скрипт смотрит текущие файлы, файлы `.env` под контролем версий и
добавленные строки всей истории коммитов. Значение печатает только с
маской. Отдельно глазами проверь `.env.example`: туда иногда по ошибке
кладут настоящее значение вместо заглушки. И проверь, что `.env` записан
в `.gitignore`.

### 2. Ключи в коде и в клиентской части

Всё, что попадает в браузер, может прочитать любой посетитель: открыть
код страницы и найти ключ. Поэтому:

- Секретные ключи (оплата, нейросети, служебный ключ базы, токен бота)
  живут только на сервере, в переменных окружения.
- Переменные с публичной приставкой (`NEXT_PUBLIC_`, `VITE_`,
  `REACT_APP_`, `PUBLIC_`) уходят в браузер. В них не должно быть ничего
  секретного. Проверь каждую.
- У Supabase два ключа: публичный (anon, publishable) можно отдавать в
  браузер, служебный (service_role, secret) только на сервере. Скрипт
  отмечает JWT, их проверяй глазами, какой это ключ.
- После сборки поищи ключи в готовых файлах (папка сборки), а не только в
  исходниках: так видно, что реально уйдёт посетителю.

### 3. Доступ к базе

Самая частая дыра у сайтов на Supabase: таблица без правил доступа (RLS),
и любой посетитель с публичным ключом читает или меняет все строки.

- Для каждой таблицы: включён ли RLS и есть ли политики. Если подключён
  инструмент Supabase для агента, запроси у него отчёт безопасности
  (advisors) по живой базе, а не только по файлам миграций.
- Бывает, что RLS выключен сознательно, а права проверяет сервер. Это
  нормально, если у ролей `anon` и `authenticated` реально нет прав на
  таблицу. Проверяется запросом к `information_schema.role_table_grants`.
- Без Supabase смысл тот же: запрос к базе должен брать пользователя из
  его сессии, а не из параметра, который прислал браузер.

### 4. Права проверяются на сервере

Спрятать кнопку «удалить» в интерфейсе не защита: запрос можно отправить
напрямую. Пройди каждую серверную функцию, которая меняет данные:

- перед записью есть проверка, кто это и можно ли ему;
- личность берётся из сессии или токена, а не из поля `userId` в теле
  запроса;
- админка проверяет права на сервере до ответа, а не только редиректом в
  браузере;
- адрес вида `/api/orders/123` отдаёт заказ только его владельцу, а не
  любому, кто подставил чужой номер.

### 5. Лимиты запросов

Без лимита форму заливают спамом, а перебором подбирают коды
подтверждения. Смотри в первую очередь: вход, сброс пароля, код из письма
или СМС, форма заявки, отправка в Telegram, всё, что вызывает платный
сервис (нейросеть, СМС). Защита хостинга на входе помогает, но перебор
кода без лимита опасен почти всегда.

### 6. Формы, ввод и XSS

- На сервере проверяется каждое поле: тип, длина, формат. Удобно схемой
  (Zod, Pydantic и похожие).
- Текст от пользователя не вставляется как HTML. Ищи
  `dangerouslySetInnerHTML`, `v-html`, `innerHTML`: если туда попадает
  чужой ввод без очистки, это опасно.
- Запросы к базе с параметрами, а не склейкой строк из ввода.
- В базу пишутся только перечисленные поля, а не всё тело запроса
  целиком: иначе посетитель допишет себе роль админа или статус «оплачено».
- Токены входа не лежат в `localStorage`, лучше cookie с флагами
  `HttpOnly`, `Secure`, `SameSite`.

### 7. Вебхуки

Каждый вебхук (оплата, Telegram, любой сторонний сервис) проверяет
подпись или секрет до обработки. Проверь каждый файл отдельно: одна
непроверенная среди проверенных частая находка.

### 8. Заголовки безопасности

Смотри конфиг хостинга или фреймворка (`next.config`, `vercel.json`,
конфиг nginx) и ответ живой страницы:

- `Strict-Transport-Security`: только https;
- `X-Content-Type-Options: nosniff`;
- `X-Frame-Options` или `frame-ancestors`: сайт нельзя вставить в чужую
  рамку;
- `Content-Security-Policy`: откуда можно грузить скрипты;
- `Referrer-Policy`.

### 9. Что ещё стоит пройти

- Уязвимые зависимости: `npm audit`, `pnpm audit`, `pip-audit`. Критичные
  и высокие в отчёт, остальное одной строкой счётом.
- Ошибки наружу без стектрейсов, путей на диске и версий библиотек.
- Загрузка файлов: лимит размера, проверка типа по содержимому.
- Сервер не ходит по любому адресу, который прислал пользователь (запросы
  во внутреннюю сеть).
- API не отдаёт лишнего: чужие почты и телефоны в общем списке.
- Редирект по параметру из адреса только на свои домены.
- В логах нет токенов, паролей и полных тел запросов.
- Пароли, если они есть, хранятся хешем bcrypt или argon2, а не открыто.

## Если ключ утёк

Порядок важнее скорости. Не пытайся тихо «замести» коммит.

1. **Остановиться.** Не выкатывать, не продолжать другую работу.
2. **Сообщить владельцу** прямо и одной фразой: какой ключ, где лежал, кто
   мог его видеть (публичный репозиторий, код страницы, чат).
3. **Сменить ключ** в панели сервиса: выпустить новый, старый отозвать.
   Удаление из кода без смены ключа не помогает: старый уже скопирован.
   Новый ключ кладётся в переменные окружения, не в код. Смену делает
   владелец или агент по его прямому слову.
4. **Искать похожие.** Тот же ключ в других файлах, проектах, ветках;
   другие ключи того же сервиса; `scan_secrets.py` по всем связанным
   папкам. Утечка редко бывает одна.
5. **Проверить последствия:** расход и журнал запросов в панели сервиса
   за последние дни.
6. Чистка истории git возможна, но это необратимая операция для всех
   копий репозитория: только по слову владельца и после смены ключа.

## Формат отчёта

Один пункт, один блок:

```
**N. <название проверки>**: есть проблема / нет / не применимо.
Что нашёл или что проверил и почему чисто, одно-два предложения.
Простыми словами: чем это грозит владельцу.
Файл: путь/к/файлу:строка (если есть).
Опасность: критично / средне / мелочь.
```

В конце итог: сколько реальных находок, самая опасная первой, и вопрос:
что чинить сейчас.

Короткий пример блока:

```
**2. Ключи в клиентской части**: есть проблема.
Токен Telegram-бота лежит в переменной с приставкой NEXT_PUBLIC_ и
попадает в код страницы.
Простыми словами: любой посетитель может слать сообщения от имени бота.
Файл: app/contact/form.tsx:14
Опасность: критично. Ключ считать утёкшим, порядок в разделе «Если ключ утёк».
```

## Типичные ошибки

- Чинить по ходу аудита. Владелец получает изменения, которых не
  понимает, а отчёт теряется.
- Проверять только текущие файлы и забыть историю git.
- Верить файлам миграций вместо живой базы: на проде могли поменять руками.
- Удалить ключ из кода и не сменить его.
- Писать «выглядит нормально» без команды или строки, которая это
  доказывает.
- Отчёт техническим языком. Владелец должен понять, чем грозит каждая
  находка, без словаря.

## Чек-лист перед сдачей отчёта

- [ ] Стек определён, неприменимые пункты отмечены с причиной.
- [ ] `scan_secrets.py` прогнан, вывод в отчёте.
- [ ] Публичные переменные окружения проверены по одной.
- [ ] Доступ к базе проверен по живой базе, а не только по миграциям.
- [ ] Каждая серверная функция записи проверена на права.
- [ ] Лимиты на чувствительных формах и кодах.
- [ ] Заголовки сверены по ответу живой или локальной страницы.
- [ ] У каждой находки: файл, строка, опасность, объяснение простыми словами.
- [ ] Ни одной строки кода не изменено до «да» владельца.

## Связи с другими скиллами набора

- `website-build`: сборка сайта; этот аудит его обязательный шаг перед
  выкатом, если есть форма, база или вход.

## Что устаревает первым

Форматы ключей сервисов (приставки меняются), названия ключей Supabase и
его инструменты проверки, команды аудита зависимостей. Сам список проверок
и порядок при утечке не устаревают. Проверено на октябрь 2026.

## Глубже

Разборы реальных аудитов и настройку проверки под ваш стек и команду
студия AIVFX показывает в работе и в обучении: https://aivfx.ru.