После доработки сайта ИИ-агентом проверьте API в двух местах: кому он разрешает читать и менять данные и как отвечает на неверные запросы. Для этого хватит тестовой копии сайта, учётных записей с разными правами и списка запросов, которые затронула правка. Ниже — порядок проверки для владельца бизнеса и разработчика: от заказа, который видит только его покупатель, до ошибки, после которой сайт должен продолжать работу.
С чего начать проверку API после правок ИИ-агента?
Сначала попросите разработчика перечислить, какие запросы к API затронула правка. Если агент менял корзину, в список могут попасть добавление товара, изменение количества и оформление заказа. Если менял кабинет — просмотр заказов и изменение их статуса. Названия запросов лучше взять из проекта: по памяти легко пропустить действие, которое вызывает сайт в фоновом режиме.
Проверяйте на тестовой копии с пробными товарами и заказами. Подготовьте гостевой вход и учётные записи для ролей, которые есть на вашем сайте: например, покупателя и сотрудника магазина. Для проверки чужого заказа нужны два разных покупателя. Запишите, кто создал каждый пробный заказ, иначе при отказе в доступе будет трудно понять, сработала защита или вы просто указали неверный номер.
Перед запуском проверок сохраните состояние сайта и порядок возврата к прежней версии. Особенно если агент менял общие настройки доступа: одна правка способна затронуть и кабинет, и оформление заказа. Порядок действий описан в материале об откате сайта перед публикацией правок Claude Code.
Как проверить, что API не открывает чужие заказы?
Начните с обычного сценария. Покупатель создаёт пробный заказ и открывает его в кабинете. Затем под учётной записью другого покупателя отправьте запрос на просмотр этого же заказа. API должен отказать в доступе и не вернуть содержимое заказа. Повторите проверку для изменения: второй покупатель не должен поменять состав, адрес доставки или статус чужого заказа, если такие действия вообще доступны через API сайта.
Отдельно проверьте запрос без входа в аккаунт. Закрытая часть API не должна выполнять его только потому, что в запросе указан существующий номер заказа. Если на сайте есть роль сотрудника, проверьте её по согласованным правилам: какие заказы сотрудник видит и какие действия ему разрешены. Не переносите права покупателя на сотрудника или наоборот лишь потому, что так предложил агент.
Разработчику удобно собрать эти случаи в повторяемые тесты. Один и тот же запрос выполняется с разными учётными записями, а тест проверяет доступ и содержимое ответа. Проверка доступа к чужим объектам входит в описание скилла API Security Testing для Claude Code (Термос Беспалова, «API Security Testing»). Скилл поможет составить проверки, но ожидаемые права задаёт владелец сайта вместе с разработчиком.
Если правка затронула оформление заказа, проверка прав доступа ещё не подтверждает работу всей покупки. После неё отдельно пройдите путь до оплаты по сценарию из статьи о проверке оплаты заказа после правок Claude Code.
Как проверить обработку ошибок без технического опыта?
Возьмите каждый запрос из списка и попробуйте отправить его с неполными или неверными данными. Для корзины это может быть товар, которого нет в тестовом каталоге, или количество в неподходящем формате. Для заказа — отсутствие обязательного поля. Сайт должен дать понятный отказ, не создавать случайный заказ и не менять уже сохранённые данные.
Затем проверьте повторный запрос. Например, отправьте изменение количества товара дважды и посмотрите на корзину. Результат должен соответствовать правилу сайта: если запрос задаёт итоговое количество, повтор не должен добавлять товар ещё раз. Это правило разработчик фиксирует до теста, иначе проверка превратится в спор о том, что «имелось в виду».
Посмотрите и на сообщение об ошибке. Покупателю достаточно понять, что исправить или когда повторить действие. Технические подробности внутренней работы сайта оставьте в журнале для разработчика; в ответе API их быть не должно. После неудачного запроса сразу выполните правильный: так вы увидите, продолжает ли работать тот же участок сайта.
Зафиксируйте результат в короткой таблице. Её можно передать разработчику или использовать как основу для автотестов:
| Сценарий | Что отправить | Что проверить |
|---|---|---|
| Чужой заказ | Покупатель открывает заказ другого покупателя | Доступ закрыт, содержимое заказа не раскрыто |
| Запрос без входа | Гость обращается к закрытому действию | Действие не выполнено |
| Неверные данные | Запрос с пропущенным обязательным полем | Есть понятный отказ, данные не изменились |
| Повтор запроса | Одно и то же изменение отправлено ещё раз | Итог соответствует правилу корзины |
| Восстановление после ошибки | Правильный запрос после неудачного | Действие выполняется, сайт отвечает |
Когда сценарии повторяются при каждой публикации, попросите разработчика превратить их в автотесты и запускать перед выпуском правок. Сами тесты тоже стоит просмотреть: они должны проверять результат запроса и права доступа, а не только то, что сервер прислал ответ. Такой порядок связывает работу ИИ-агента с проверкой результата, о которой говорится в руководстве по Claude Code на русском (sfrangulov, «claude-code-handbook-ru»).
Какие ошибки чаще всего мешают проверке?
- Проверяют только действия владельца заказа. Добавьте запросы от другого покупателя и гостя: именно они показывают, где проходит граница доступа.
- Открывают страницу в браузере и считают API проверенным. Отправьте запрос к затронутому действию отдельно: интерфейс способен скрыть кнопку, но сам запрос всё ещё требует проверки прав.
- Просят агента «проверить безопасность» без списка ролей и правил. Запишите, кто видит заказ и кто меняет его статус, затем попросите тесты под эти правила.
- Принимают любой отказ за успех. После неверного запроса проверьте, что данные не изменились, а правильный запрос всё ещё работает.
- Проверяют только изменённый запрос. Если правка коснулась общего механизма входа или доступа, повторите тесты для остальных закрытых действий сайта.
Для ближайшей доработки начните с одного затронутого действия: создайте два пробных аккаунта, проверьте запрос от владельца и постороннего покупателя, затем отправьте неверные данные. Запишите ожидаемый и фактический результат каждого шага. Этот список уже даст разработчику основу для исправления и повторного теста перед публикацией.
