Чтобы проверить права доступа на сайте после вайбкодинга, составьте список разрешений для каждой роли, затем попробуйте выполнить запретные действия через прямые ссылки и запросы к серверу. Claude Code поможет найти проверки в коде и подготовить тесты, но его отчёт нужно подтвердить результатами запусков. Ниже разберём проверку на примере сайта с каталогом: как отделить гостя от сотрудника, проверить админку и убедиться, что сервер отклоняет чужие команды.
Почему скрытая кнопка не защищает админку и API?
Допустим, сотрудник видит каталог, а кнопку изменения цены разработчик оставил только администратору. Интерфейс выглядит правильно. Но если сервер принимает команду изменения цены от любого пользователя после входа, сотрудник отправит такой запрос в обход кнопки. Адрес запроса можно найти в коде страницы или во вкладке Network инструментов разработчика в браузере.
API — это интерфейс, через который страница запрашивает сведения и отправляет команды серверу. Серверу нужно проверять право на каждое действие: открыть черновик товара, изменить цену, опубликовать карточку. Сам факт входа на сайт ещё не даёт разрешения на эти операции.
Отдельная граница доступа бывает на уровне базы. В разборе безопасности вайбкодинга на Хабре отмечают, что у Supabase есть Row Level Security, то есть правила доступа к отдельным строкам таблиц. Наличие такого механизма само по себе не подтверждает, что правила проекта настроены верно (Хабр, «Гайд по безопасности вайб-кодинга: что сделать, чтобы не слить данные в прод»).
Начните с простого вопроса к разработчику или Claude Code: «Где сервер проверяет разрешение на изменение цены?» Ответ должен содержать конкретный обработчик запроса и условие проверки. Ссылка только на скрытую кнопку в интерфейсе этот вопрос не закрывает.
Как подготовить роли и безопасную среду для проверки?
Используйте отдельную тестовую копию сайта с вымышленными товарами. Проверьте, что она обращается к тестовой базе: похожий адрес страницы ещё ничего не гарантирует. Отключите рабочие интеграции, чтобы тест публикации или удаления не затронул основной сайт.
До изменений сохраните исходный код и базу. Резервировать обе части проекта рекомендует и руководство по безопасному вайб-кодингу для малого бизнеса (Kaspersky, «Практическое руководство по безопасному вайб-кодингу для SMB»). Уточните, как восстановить копию: один архив без понятного способа возврата не поможет быстро отменить ошибку.
Затем письменно задайте правила. Для учебного каталога подойдёт такой набор:
- Гость открывает опубликованные карточки, но не видит черновики и не меняет товары.
- Сотрудник редактирует товары своего раздела, но не публикует их и не меняет роли.
- Администратор публикует товары и назначает разрешения через отдельные действия в админке.
- Сотрудник другого раздела не получает доступ к чужим черновикам, даже если знает их адреса.
Это пример правил, а не готовая схема для любого бизнеса. Если сотрудникам нужен общий каталог, измените условие до проверки. Иначе Claude Code примет вашу рабочую логику за ошибку или, наоборот, закрепит лишние разрешения в тестах.
Создайте отдельные тестовые учётные записи. Для каждой откройте свой профиль браузера или отдельную сессию: несколько вкладок одного профиля обычно используют общий вход. Пароли и ключи в запрос к ИИ не вставляйте, для анализа достаточно названий ролей и структуры проекта.
Что поручить Claude Code при проверке прав доступа?
Сначала попросите исследовать код без изменений. Иначе помощник начнёт исправлять предполагаемые проблемы раньше, чем вы согласуете ожидаемое поведение. Дайте ему правила ролей и ограничьте работу тестовой средой.
Пример задания: «Найди маршруты админки и API, которые читают черновики, меняют товары, публикуют их и назначают роли. Для каждого укажи файл, обработчик и место серверной проверки прав. Проверь, откуда сервер получает роль и как определяет доступ к конкретному товару. Пока ничего не меняй. Отдельно перечисли места, которые не удалось проверить».
Попросите проверить, не доверяет ли сервер роли из тела запроса, адресной строки или браузерного хранилища. Пользователь может изменить эти значения. Источник разрешений должен быть под контролем сервера: например, серверная сессия или токен, подпись и срок действия которого сервер проверяет.
Следующее задание — подготовить тесты по согласованным правилам: «Для каждого запрета добавь тест отказа, а для разрешённого действия — тест успешного выполнения. Используй тестовую базу. После запретной команды проверяй ответ и состояние записи. Не меняй ожидаемый результат ради прохождения теста».
Просите разделять находки в коде и подтверждённые ошибки. Фраза «в обработчике нет проверки» ещё требует изучить общий защитный слой, через который проходит запрос. А сообщение «тесты прошли» требует списка команд и результатов. Разобраться с такими выводами поможет материал о том, как проверить отчёт Claude Code об уязвимостях сайта.
Как проверить админку и API в обход интерфейса?
Проверяйте только свой проект или среду, на тестирование которой у вас есть разрешение. Начните с браузера, затем повторите действия через запросы. Для каждого сценария сохраните роль, действие, ожидаемый результат и фактический ответ.
- Откройте прямую ссылку на страницу редактирования без входа. Проверьте также запрос, которым эта страница получает черновик. Перенаправление на форму входа недостаточно, если API всё равно возвращает содержимое.
- Войдите сотрудником и попробуйте открыть страницу назначения ролей по прямому адресу. Затем проверьте сам запрос изменения роли. Сервер должен отклонить действие, даже если меню админки скрыто.
- В тестовой сессии администратора откройте вкладку Network и найдите запрос изменения товара. Повторите его способом, который поддерживает браузер или тестовый инструмент, но с сессией сотрудника. Убедитесь, что в запросе не остались полномочия администратора.
- В запросе сотрудника замените идентификатор своего тестового товара на идентификатор товара другого раздела. Проверьте чтение и изменение: разрешение на одно действие не означает разрешения на другое.
- Попробуйте добавить в запрос поле роли или заменить его значение. Отдельно проверьте, что обычное редактирование учётной записи не позволяет назначить себе права администратора.
- После выхода повторите запрос со старым сеансовым ключом. Если проект использует токены, проверьте согласованное поведение после выхода, истечения срока и отзыва доступа.
Отказ должен подтверждаться на сервере. Надпись «Нет доступа» на странице ничего не доказывает, если ответ API содержит черновик. После запрета на изменение заново прочитайте товар через разрешённую учётную запись и убедитесь, что цена и статус остались прежними.
Попросите Claude Code превратить ручные сценарии в повторяемые тесты. Затем проверьте сами тесты: например, на отдельной ветке временно уберите конкретную проверку прав и убедитесь, что соответствующий тест падает. Такой приём подробно разбирает статья о проверке того, что тесты Claude Code находят ошибки. После эксперимента верните защиту и повторите запуск.
Типичные ошибки при проверке прав доступа
- Проверять только администратора. Начните с гостя и сотрудника: именно для них нужны проверки отказа.
- Ограничиться адресом админки. Проверьте API отдельно, включая команды изменения и публикации.
- Считать любой отказ доказательством защиты. Ошибка соединения или сбой сервера тоже мешают действию, поэтому выясните причину ответа.
- Искать только различия между ролями. Два сотрудника с одинаковой ролью могут иметь разные права на товары своих разделов.
- После исправления запускать только тест запрета. Убедитесь, что администратор по-прежнему выполняет разрешённое действие.
- Принимать пересказ Claude Code за протокол проверки. Сохраните сценарии, команды запуска и фактические результаты без паролей и сеансовых ключей.
Если проверку передаёте разработчику, оформите её как отдельную задачу: список ролей, границы доступа, тестовая среда, сценарии обхода интерфейса и повторный запуск после исправлений. Такой объём понятнее, чем просьба «посмотреть безопасность сайта», а результат можно принять по конкретным проверкам.
Начните с одного действия, которое заметно влияет на работу сайта, например публикации товара. Опишите, кому оно разрешено, проверьте прямой запрос под каждой ролью и сохраните тест. Затем тем же способом пройдите изменение цен, доступ к черновикам и назначение прав.
