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

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

Зачем

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

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

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

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

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

Статичная страница-визитка без форм и базы: достаточно пунктов 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.