Как проверить свой сервис на дыры

Практика 1. Закрытая база: посторонний не читает чужие записи

Типичная ошибка: приложение опубликовано, публичный ключ в коде страницы, защита включена на главной таблице заказов — и забыта на таблицах профилей и отзывов

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

• Таблица без правила открыта по умолчанию. Условие доступа появляется только тогда, когда его написали.
• Служебный ключ проходит мимо всех правил. В Supabase это service_role: место — серверная часть и переменные окружения.
• Правило пишется на каждую таблицу отдельно. Одна забытая таблица открывает свои строки полностью.
• Платформа сама показывает список дыр. Security Advisor в панели Supabase перечисляет таблицы без защиты, раз в неделю приходит письмо с той же сводкой.
• Объём хранения проверяется вместе с доступом. Старые копии и хранилище прошлой версии живут дольше памяти о них.

Мой сервис [ВСТАВИТЬ_НАЗВАНИЕ] работает на [ВСТАВИТЬ_ПЛАТФОРМУ_БАЗЫ, например Supabase] и уже принимает данные реальных пользователей.

Проведи инвентаризацию доступа к базе. Ничего не меняй.

1. Перечисли таблицы, которые сервис отдаёт наружу через API. По каждой назови файл, из которого ты её взял: файл миграции, описание схемы, настройка проекта. Таблицы, которых нет в файлах, не придумывай: вынеси их в список «посмотреть в панели».
2. По каждой скажи: включена ли построчная защита, какие политики написаны, какие роли под них попадают. Имя каждой политики выпиши целиком.
3. Для каждой незакрытой таблицы объясни обычными словами, что именно увидит посторонний человек без логина: какие поля, чьи записи, сколько строк.
4. Найди все места, где используется служебный ключ, который обходит правила. По каждому месту верни строку вида «путь к файлу : номер строки : имя переменной : сервер или браузер». Отдельно перечисли файлы, попадающие в сборку страницы, и скажи прямо, встречается ли служебный ключ хотя бы в одном из них. Само значение ключа в чат не выводи ни при каких условиях, достаточно имени переменной.
5. Верни таблицу «таблица — защита — что видит посторонний — насколько срочно» и предложи порядок закрытия. Правки покажи мне на согласование, применять их я скажу отдельно.

Готово, когда: список таблиц, отдаваемых наружу, записан файлом, и напротив каждой строки стоит имя политики; Security Advisor показывает ноль таблиц без защиты; служебного ключа нет ни в одном файле сборки и репозитория; по каждому старому хранилищу принято письменное решение — оставить или удалить.

Практика 2. Проверка вторым аккаунтом: чужая запись и чужой счёт

Типичная ошибка: платный раздел скрыт в браузере, а адрес выдачи данных отвечает всем вошедшим одинаково — независимо от оплаты и владения записью

Автоматика хорошо ищёт то, у чего есть узнаваемый образец: открытый ключ, известная дырявая библиотека. Хуже всего она ловит другое: сервис исправно проверяет, что вы вошли, и забывает проверить, что запись действительно ваша. Cobalt в отчёте AI and Pentesting Pulse за 2026 год приводит цифру: 78% опрошенных команд ловят пропуски автоматических проверок, и хуже всего автоматика справляется как раз с чужим доступом к чужому объекту. Доля команд, полагающихся только на автоматику, за год упала с 29% до 9%. Опрошены крупные компании — проценты читаются как направление.

Рядом живут две ошибки в других обличьях: проверка оплаты сделана в браузере, и сервер не ограничивает частоту запросов. Если ваш сервис ходит в платный сервис моделей от имени пользователя, посторонний может обращаться к нему без остановки и оставить вам счёт — отраслевое название denial of wallet. Ограничение частоты закрывает и перебор чужих номеров, и этот счёт.

Разбери контроль доступа в моём сервисе [ВСТАВИТЬ_НАЗВАНИЕ]. Сервис собран на [ВСТАВИТЬ_СТЕК, например Next.js на Vercel и база Supabase], публичный адрес [ВСТАВИТЬ_АДРЕС_САЙТА]. Ничего не меняй, собери отчёт.

1. Перечисли все адреса и запросы, где в параметрах есть номер объекта пользователя: запись, заказ, профиль, файл, сообщение. По каждому назови путь к файлу и номер строки, где адрес объявлен.
2. По каждому покажи строку кода, которая проверяет, что объект принадлежит спрашивающему. Если такой строки нет, напиши это прямо.
3. Найди проверки прав и проверки оплаты, которые выполняются только в браузере, и покажи, есть ли у каждой серверная пара.
4. Перечисли адреса, обращающиеся к платным сервисам и моделям, и скажи, где стоит ограничение частоты запросов, а где его нет.
5. Собери сценарий ручной проверки вторым аккаунтом ровно из трёх шагов. Для каждого шага дай готовую строку, которую я вставлю в адресную строку браузера: полный адрес моего сервиса вместе с номером объекта, взятым из моих же данных, без сокращений. Рядом с каждым адресом напиши, под каким аккаунтом его открывать, что я должен увидеть при исправном сервисе и что будет означать провал.
6. Верни таблицу «адрес — файл и строка — проверка владельца — проверка оплаты — ограничение частоты — риск». Правки покажи отдельным списком на согласование и жди моего слова.

Готово, когда: второй аккаунт заведён, три адреса из сценария открыты под ним, и на каждом сервис вернул отказ; по каждому платному действию названа серверная строка, которая проверяет оплату; после серии повторов сервис отвечает отказом.

Практика 3. Секреты в опубликованном продукте

Типичная ошибка: ключ сервиса вынесли в переменную с приставкой публичности, потому что «иначе фронтенд не видит», и сервис заработал с первого раза

Во фреймворках вроде Next.js переменная с приставкой NEXT_PUBLIC_ попадает в код страницы намеренно: слово public в её имени означает буквально «значение станет публичным». В Moltbook ключ базы нашли в коде страницы за минуты именно так. Вторая половина практики — история репозитория: даже убранный из текущей версии ключ старые версии помнят навсегда.

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

Проверь, какие секреты моего сервиса [ВСТАВИТЬ_НАЗВАНИЕ] могут быть видны постороннему человеку.

1. Перечисли все переменные окружения с приставкой публичности [ВСТАВИТЬ_ПРИСТАВКУ, например NEXT_PUBLIC_]. По каждой напиши, зачем она в браузере и что произойдёт, если её узнает посторонний.
2. Проверь собранный код страниц на присутствие значений, похожих на ключи и токены, по образцам: [ВСТАВИТЬ_ОБРАЗЦЫ, например для Supabase и Stripe это sb_secret_, sb_publishable_, eyJ, sk_live_, sk_test_].
3. Проверь полную историю репозитория теми же образцами и скажи, встречались ли похожие значения когда-либо.
4. По каждой находке верни строку «путь к файлу : номер строки : имя переменной : какой сервис открывает : что отозвать первым». Если находок нет, так и напиши, а список образцов, по которым ты искал, покажи мне на согласование.

Значения найденных секретов в чат не выводи ни при каких условиях. Достаточно имени переменной, файла и строки. Ничего не меняй сам: верни отчёт и порядок действий, я подтвержу каждый шаг.

Готово, когда: у каждой публичной переменной записано обоснование; поиск по сборке и по всей истории репозитория пуст; каждый найденный ранее ключ отозван и заменён — удаления строки из файла для этого мало.

Практика 4. Официальное ревью: список вместо наития

Типичная ошибка: «прогони код на уязвимости» в свободной формулировке; отчёты каждый раз про разное, сравнить два прогона невозможно

Замена наитию появилась 6 августа 2025 года: Anthropic встроила в Claude Code команду /security-review с фиксированным перечнем категорий — внедрение команд в запросы к базе, выполнение чужого кода на странице, ошибки проверки входа, обработка данных, состояние зависимостей. Одна особенность: команда смотрит изменения текущей ветки и молчит о проблемах, которые были в коде до них. Для давно опубликованного сервиса первый полный проход делается промптом с тем же перечнем, а команда встаёт гейтом на новые изменения.

Здесь важно развести две проверки. Ревью качества отвечает на вопрос «насколько этот код удобно развивать», ревью безопасности — «что здесь сделает посторонний». Пройденное ревью качества о безопасности не говорит ничего, и обратное верно. Находки сортируются по одному вопросу: что может сделать посторонний без логина — это идёт первым; дальше доступное любому вошедшему; правки, требующие прав администратора, ждут очереди.

Зависимости входят в тот же прогон отдельным блоком. У одного из моих студентов на сервере поселился майнер, приехавший через уязвимость в подключённой библиотеке; предупреждение об этой уязвимости лежало в репозитории заранее. Уязвимость CVE-2025-29927 в Next.js позволяла подделкой заголовка пропустить весь слой промежуточной проверки; безопасны версии от 15.2.3, 14.2.25, 13.5.9 и 12.3.5.

Пройди по всему коду моего сервиса [ВСТАВИТЬ_НАЗВАНИЕ] тем же перечнем категорий, что берёт команда /security-review, и разбери находки. Ничего не меняй.

Категории: внедрение команд в запросы к базе; выполнение чужого кода на странице; ошибки проверки входа и прав; небезопасная обработка данных пользователей; секреты в коде; состояние зависимостей; подробности внутренней ошибки в ответе наружу.

1. По каждой находке верни строку «путь к файлу : номер строки : категория : что сделает посторонний : сколько шагов ему нужно».
2. Разложи все находки по трём корзинам: доступно постороннему без логина; доступно любому зарегистрированному; требует прав администратора.
3. Отдельным блоком проверь зависимости: библиотеки с известными уязвимостями и версия фреймворка [ВСТАВИТЬ_ФРЕЙМВОРК_И_ВЕРСИЮ]. Номер версии возьми из файла зависимостей и назови этот файл, по памяти версию не указывай.
4. Отметь находки, которые считаешь ложной тревогой, и объясни по каждой, почему.
5. Верни план правок по порядку срочности и покажи его мне на согласование. Ничего не меняй, пока я не скажу «выполняй» по конкретному пункту.

Значения найденных секретов в чат не выводи, достаточно имени переменной, файла и строки.

Готово, когда: полный проход сделан и отчёт сохранён файлом с датой; каждая находка лежит в одной из трёх корзин; доступное без логина закрыто или стало задачей с датой; версия фреймворка выписана из файла зависимостей и сверена со списком безопасных.