Дыры сайта видно в коде раньше, чем снаружи: проверка на уязвимости, когда сайт ведут агенты

Письмо «ваш сайт уязвим» само по себе не доказывает взлом. Попросите назвать проблему и показать её на примере без чужих данных.

Владельцу нужен ответ о последствиях. Посторонний прочитает заявки, получит платный доступ или остановит приём оплаты? От этого зависит очередь ремонта.

Скриншот красного предупреждения ещё не отвечает на этот вопрос. Название старой библиотеки требует проверки: используется ли уязвимый участок в вашем сайте?

Онлайн-проверка видит то, до чего ей дали добраться. Без входа в кабинет она не проверит все действия клиента и сотрудника.

Чтение кода показывает, как сервер решает, кому отдать данные и что считать оплатой. Будущую правку можно прочитать ещё до её выпуска.

Пентест проверяет, удастся ли использовать слабое место в согласованных условиях. Он бывает с доступом к коду; провести границу только по названию услуги нельзя.

Зелёный скан означает, что проверка не нашла проблем в своём объёме. Это основание продолжать работу, а не сертификат безопасности сайта.

Уязвимость часто прячется в решении сервера. Экран спрашивает пароль, но запрос данных обходится без проверки прав. Пользователь этого не заметит.

У оплаты похожая ловушка. Настоящее уведомление от кассы ещё нужно связать с нужной покупкой: проверить заказ, сумму, товар и статус платежа.

Адрес сервера, который получает браузер, не должен быть тайной. В нашей истории проблема была в доступе к данным, а не в видимости адреса.

С подписью платежа тоже не надо бороться: она нужна. Ошибка начинается там, где её принимают за доказательство права на любой продукт.

Секреты требуют отдельной проверки. Чистый git не доказывает, что ключ не попал в вывод команды; правила для ИИ-агентов закрывают эту границу.

Другая модель читает правку без объяснений автора и ищет пропущенный запрет. Мы называем это кросс-ревью; в ленте выше есть его находки.

Менять модель полезно, но её ответ остаётся предположением до проверки. Она может пропустить дыру или объявить ошибкой допустимое поведение.

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

Тест на успешный вход не проверяет запрет читать чужой заказ. Для этой ошибки нужна отдельная проверка, иначе зелёные тесты с ней совместимы.

Приёмка не заканчивается правкой в ветке. Инженер связывает её с выпущенной версией и проверяет нужный сценарий на тестовом аккаунте.

Кто принимает работу и отвечает за выпуск, разобрано в статье об ответственности за ошибки ИИ. Критерий этой проверки: закрытая дыра.

Если на сайте появились чужие страницы или неизвестные учётки, нужен разбор инцидента. Ревью будущей правки не объяснит, что уже сделал посторонний.

Назначьте инженера, который ведёт восстановление и записывает действия. До удаления подозрительных файлов он сохраняет журналы и копию затронутого состояния.

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

Затронутые данные клиентов разбирают отдельно. Их обработка и работа агентов описаны в статье о персональных данных.

В задании на аудит безопасности сайта назовите вход, заявки, кабинет и оплату. Попросите указать объём проверки и то, кто закрывает подтверждённые находки.

Принять отчёт проще, когда каждая строка объясняет потерю для бизнеса. «Ошибка прав позволяет читать чужой заказ» полезнее владельцу, чем балл без сценария.

Стоимость зависит от этого объёма. Публичную визитку и кабинет с ролями нельзя сравнить по одной цене «проверки сайта» без списка проверяемых функций.

Неясно, кто в компании сможет вести такую работу? Тест для руководителя помогает выбрать следующий шаг для разработки.

На сайте, который мы ведём, проверка кода и закрытие находок идут задачами подписки «Один проект».

Тариф стоит 250 000 ₽ в месяц на 07.10.2026. Отдельный пентест согласуют со специалистами по безопасности.

Наш счётчик на 07.10.2026: 7 063 коммита за 98 дней с 1 июля. Инженер ведёт машину агентов; темп не измеряет безопасность.

1. Исправный экран не доказывает правильные права. Включите в проверку запросы данных и оплату.

2. Сканер, чтение кода и пентест дополняют друг друга. Согласуйте, что именно проверят.

3. Ответ модели подтверждают сценарием на тестовых данных. Принимайте доказательство, а не уверенный текст.

4. Найденную ошибку закрывают правкой и повторной проверкой. Сохраните обе в своём проекте.

5. После взлома сначала ограничивают ущерб и сохраняют следы. Восстановление проверяют вместе с закрытием причины.