Подготовьте данные и пределы проверки
Используйте свою тестовую среду, два обычных аккаунта с разными объектами и отдельный аккаунт администратора, если такая роль предусмотрена. Не переносите в тестовую базу реальные телефоны, документы и платёжные ключи ради удобства. Для покупок используйте тестовый режим поставщика, а для дорогих операций — безопасный предел бюджета.
Зафиксируйте версию приложения и перечень проверяемых сценариев. Таблица «действие → ожидание → результат → задача» полезнее общего заключения «всё безопасно». Это редакционный набор практических проверок RoboGuard, а не полная сертификация по OWASP ASVS. Требования ASVS можно использовать для более глубокого аудита с учётом состава проекта.
Подробнее в первоисточнике: OWASP ASVS: требования к проверке безопасности приложения.
Доступ: кто и что может сделать
Для учебного сервиса документов проверка выглядит так: пользователь А создаёт файл, Б пробует выполнить те же операции с этим тестовым файлом. Ожидается отказ и отсутствие изменения данных. Проверяется ответ сервера, а не только видимость кнопки. У администратора должны оставаться только действительно предусмотренные возможности.
| Проверка в своей среде | Критерий приёмки |
|---|---|
| Гость открывает приватную запись или её файл | Содержимое недоступно; ошибочный ответ не раскрывает секретные поля. |
| Вошедший Б читает, меняет или удаляет объект А | Каждое запрещённое действие отклонено, данные А сохранены. |
| Обычный пользователь обращается к функции администратора | Сервер отклоняет действие независимо от интерфейса. |
| Пользователь вышел или сессия отозвана | Повторное использование этой сессии не даёт прежний доступ. |
| Роль пользователя изменилась | Новые ограничения действуют на сервере, включая уже открытый экран. |
Подробнее в первоисточнике: OWASP: проверка прав при каждом запросе.
Платежи и дорогие операции
Запишите цену и состав заказа на сервере до отправки покупателя в банк. Затем проверьте успешную оплату, отказ и неопределённый результат. Отдельно повторите одно уведомление: доступ или заказ не должны создаться повторно. Сначала определите источник истины для вашего провайдера, затем проверяйте обработчик по его документации.
Если продукт генерирует текст, изображения, отправляет SMS или обрабатывает файлы, проверьте исчерпание лимита. Нужен понятный отказ до очередной платной операции и возможность вернуться к обычной работе после предусмотренного восстановления квоты. Не проверяйте предел бесконтрольным потоком запросов к рабочему сервису.
- Изменённая в браузере цена не меняет сумму серверного заказа.
- Переход на страницу успеха без подтверждённого платежа не выдаёт покупку.
- Повтор уже обработанного события не продлевает подписку второй раз.
- Ошибка поставщика не списывает внутренний баланс как за выполненную работу без предусмотренного правила компенсации.
- Предел числа, размера и длительности задач действует на сервере.
Подробнее в первоисточнике: ЮKassa: проверка подлинности входящих уведомлений; OWASP API4: расход ресурсов и платных интеграций.
Файлы, ключи и настройки релиза
Проверьте именно итоговую публикацию: браузерную сборку, доступные файлы, журнал запуска и конфигурацию окружения. Отсутствие ключа в последней версии исходника не говорит, что его не осталось в старом архиве или истории репозитория. Для Vite переменные с клиентским префиксом VITE_ могут попасть в отправляемый посетителю код; название .env не делает их секретными.
Для проекта с Supabase проверьте доступы к таблицам и политики RLS в опубликованной среде, а не только настройки локальной базы. Таблица с разрешённым доступом и без подходящих ограничений не становится приватной от наличия экрана входа. Серверные secret/service_role-ключи не размещаются в клиенте.
- Проверьте доступные браузеру файлы и ответы на наличие серверных ключей и отладочных данных.
- Проверьте, что тестовые учётные записи и административные функции не опубликованы без нужных ограничений.
- Убедитесь, что секреты рабочего и тестового окружения различаются и могут быть отозваны независимо.
- Проверьте опубликованные правила доступа к базе на госте, владельце и другом пользователе.
Подробнее в первоисточнике: Vite: переменные окружения в клиентской сборке; Supabase: Row Level Security и права таблиц; Supabase: публичные и серверные API-ключи.
Что произойдёт при ошибке и после подключения защиты
Восстановите тестовую копию важных данных и убедитесь, что приложение её читает. Наличие задания резервного копирования ещё не доказывает возможность восстановления. Назначьте человека, который увидит сбой доставки webhook, рост ошибок или расход бюджета, и определите, какое действие он может выполнить.
После изменения DNS и подключения RoboGuard повторите нормальный путь через публичный домен: вход, запрос API, загрузка, отправка формы и уведомление интеграции. Проверьте, что машинному клиенту не требуется браузерная проверка, личные ответы не отдаются из общего кеша, а прямой доступ к origin закрыт там, где это предусмотрено архитектурой. Подтверждайте правила по фактическому состоянию подключения.
- Ошибка пользователя понятна и не показывает пароль, токен или внутреннюю строку подключения.
- Повтор после сетевого обрыва не создаёт второй заказ или вторую дорогую задачу.
- Есть проверенный способ откатить релиз или вернуть прежний маршрут.
- Сохранённая конфигурация, оплата и реальное прохождение трафика проверены как отдельные события.
Когда релиз нужно остановить
Чужие данные доступны, серверный секрет раскрыт, покупка выдаётся без оплаты или повтор запроса меняет баланс дважды — это конкретные причины отложить открытый запуск затронутого сценария. Назначьте исправление и повторите проверку, которая обнаружила проблему. Не прячьте её за общим средним баллом отчёта.
Отсутствующий заголовок, замечание анализатора и подтверждённый обход доступа требуют разного разбора. Фиксируйте возможное последствие и воспроизводимость. Если проверка не выполнена, так и запишите: «не проверено», а не «проблем нет». Внешняя проверка одной страницы не заменяет эту приёмку.