Проверка своего сайта на уязвимости по URL

Начать проверку своего сайта

Кнопка ведёт в существующее подключение проекта. После входа добавьте публичный URL без токенов и секретных параметров, разместите проверочный файл либо DNS-запись и подтвердите разрешение. Сканирование не начинается от самого открытия руководства. Указывайте собственный ресурс или адрес, на проверку которого есть явное разрешение. Это не сервис проверки надёжности чужого магазина и не антивирус для компьютера.

Что входит во внешнюю проверку

Внешний профиль рассматривает транспорт, защитные заголовки, применимые cookies, CORS и поддерживаемые признаки ошибочной публикации. Таблица ниже разделяет наблюдение и границу вывода. Cookie отсутствует в ответе — это не основание объявить проверенными все сессии приложения. Заголовки главной страницы не описывают каждый API-маршрут. У Nuclei используются отобранные профили, а не весь каталог движка; набор зависит от технологии и бюджета.

Первичные источники: OWASP: HTTP Headers · MDN: CORS

Продолжить: Безопасность вайбкодинга: как проверить приложение перед запуском

Как проходит проверка

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

Как выглядит полезный отчёт

Полезная находка содержит проверяемую цель, правило, наблюдение, уверенность, последствия и следующий шаг. Секретные значения маскируются. Учебный пример ниже относится только к локальному стенду: конфигурация содержит вымышленные данные. Частичный результат отдельно объясняет ограничение, например ответ 429. Технический сбой тоже не равен чистому отчёту. Сравнивать запуски имеет смысл при одинаковой области и известных изменениях сборки.

python3 access-fixture.py
# В другом терминале: до исправления — 200 с чужим объектом
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
# После — 403; doc-a остаётся доступен пользователю a
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Первичные источники: OWASP: HTTP Headers · MDN: CORS

Продолжить: Проверка безопасности API с тестовыми аккаунтами

Почему ответ 200 ещё не означает утечку

Многие SPA возвращают index.html со статусом 200 на любой неизвестный путь. Такой ответ на /.env не является конфигурационным файлом. В нашем тесте HTML fallback исключается, а структурированный набор синтетических переменных подтверждает публикацию конфигурации. Не проверяйте работоспособность найденного секрета обращением к чужому сервису. Сначала определите его назначение внутри своего проекта, ограничьте распространение и отзовите полномочия у провайдера.

Как понимать CORS заголовки и сертификат

HTTPS защищает соединение, но не решает, кому разрешён документ. CORS описывает ограничения чтения ответа браузером и не заменяет серверную авторизацию. Отсутствие CSP само по себе не доказывает XSS; применимость заголовка зависит от типа ответа. Не копируйте один набор настроек на HTML, JSON и скачивание файлов без проверки поведения. Источники рядом с таблицей объясняют назначение отдельных механизмов.

Первичные источники: OWASP: HTTP Headers · MDN: CORS

Продолжить: Утечка .env .git или API-ключа: как закрыть доступ и проверить исправление

Чем отличаются бесплатная и расширенная проверки

Актуальные цены и лимиты показаны из каталога приложения ниже. Free предназначен для знакомства с коротким внешним профилем; расписаний и мониторинга зависимостей в нём нет. Платные профили позволяют подготовить авторизацию и расширить поддерживаемые проверки. Более высокий тариф не превращает каждое наблюдение в доказанную уязвимость: качество поддерживаемых правил одинаковое, отличаются объём и управление.

Что делать после результата

Сначала разберите подтверждённые утечки и ошибки доступа. Исправьте причину в приложении или публикации, затем повторите проверку. Если находок нет, посмотрите пропуски и неприменимые правила, прежде чем делать вывод о готовности релиза. Для приватного API подготовьте аккаунты; для библиотек — точный инвентарь. Регулярный контроль нужен после изменений, а не только в день первого подключения.

Продолжить: Мониторинг CVE и зависимостей вашего приложения

Воспроизводимые примеры и материалы

Проверено: guides-1 · Python 3.13.0 · PyJWT 2.15.1

Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.

• launch-checklist.csv — редактируемый шаблон
• Локальный HTTP-стенд: уязвимый и исправленный режимы

Протокол проверки примера: версии, действия и наблюдения

Вопросы и ответы

Автор и источники

Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.

• OWASP: HTTP Headers
• MDN: CORS