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

Что именно показывает внешняя проверка

Публичный анализ оценивает наблюдаемое поведение веб-сервера и страницы. Он отвечает на практические вопросы: открывается ли HTTP-версия, куда она перенаправляет, действителен ли сертификат, не запрашивает ли HTTPS-страница ресурсы по HTTP, какие заголовки присутствуют в ответе и с какими атрибутами устанавливаются cookies.

Это уже полезный слой контроля. Ошибка в нем может затронуть посетителей даже при хорошо защищенном сервере: например, форма загружается по HTTPS, но сторонний скрипт запрашивается по незашифрованному протоколу. При этом вывод «заголовок присутствует — сайт безопасен» неверен. Заголовки снижают отдельные классы рисков, но не исправляют ошибки приложения.

Диагностический алгоритм

1. Проверить HTTP, HTTPS и цепочку перенаправлений

Начните с двух вариантов адреса: http://example.ru/ и https://example.ru/. HTTP-версия должна переводить пользователя на HTTPS без промежуточного возврата к незашифрованному протоколу. Проверьте также варианты с www и без него, если оба доменных имени доступны.

Зафиксируйте каждый ответ в цепочке, его статус и конечный URL. Обычно для постоянного перехода применяют код 301 или 308. Сам по себе код 302 не создает уязвимость, но может указывать на временную либо непоследовательную настройку. Опаснее циклы, длинные цепочки, переход на другой домен без понятной причины и доступность одной и той же страницы одновременно по HTTP и HTTPS.

2. Оценить TLS-сертификат

Браузер должен принимать сертификат без предупреждения. Проверьте срок действия, соответствие имени сертификата домену и полноту цепочки доверия. Сертификат для www.example.ru не обязательно покрывает example.ru, поэтому каждый публичный вариант имени нужно открывать отдельно.

Наличие замка в браузере означает, что текущее соединение установлено без обнаруженной браузером ошибки. Оно не подтверждает надежность CMS, отсутствие вредоносного кода или корректность бизнес-логики.

3. Найти mixed content

Mixed content возникает, когда документ открыт по HTTPS, а изображение, шрифт, таблица стилей, iframe, аудио, видео или скрипт запрашивается по HTTP. Браузеры могут автоматически обновлять часть адресов до HTTPS или блокировать активный контент. Поэтому проблема иногда проявляется не предупреждением, а сломанным интерфейсом или отсутствующей функцией.

Откройте инструменты разработчика, перезагрузите страницу и изучите вкладки Console и Network. Отфильтруйте запросы по http://. Проверяйте не только HTML: небезопасный адрес может находиться в CSS, подключенном скрипте, ответе API или коде стороннего виджета. Повторите проверку на шаблонах, которые подключают разные наборы ресурсов: главной, статье, форме и странице с медиа.

4. Разобрать защитные HTTP-заголовки

Заголовки нужно смотреть в конечном ответе страницы, а при необходимости — в ответах API и статических ресурсов. Важно не только наличие директивы, но и ее значение. Формально установленный заголовок может практически ничего не ограничивать.

Как интерпретировать security headers

Strict-Transport-Security сообщает браузеру, что домен следует открывать только по HTTPS в течение заданного периода. Директива начинает защищать после получения по безопасному соединению. Параметры includeSubDomains и предварительная загрузка требуют осторожности: их нельзя включать, пока все затронутые поддомены не готовы работать по HTTPS.

Content-Security-Policy ограничивает источники контента и считается одним из наиболее содержательных, но сложных для настройки заголовков. Политика с чрезмерно широкими источниками, * или необоснованными unsafe-inline и unsafe-eval дает меньше защиты. В то же время механическое ужесточение CSP способно отключить аналитику, формы, оплату или виджеты. Сначала политику сопоставляют с фактическими запросами страницы.

Для ограничения встраивания страницы используют директиву CSP frame-ancestors; старые клиенты могут учитывать X-Frame-Options. X-Content-Type-Options: nosniff запрещает браузеру угадывать тип содержимого вместо заявленного сервером. Referrer-Policy управляет объемом адреса, передаваемого в заголовке Referer. Permissions-Policy ограничивает доступ документа и вложенных фреймов к отдельным браузерным возможностям.

Проверка атрибутов cookies

Смотрите заголовки Set-Cookie в Network и итоговое состояние cookies в разделе хранилища браузера. Атрибут Secure ограничивает передачу cookie защищенным соединением. HttpOnly закрывает доступ из JavaScript и обычно уместен для сессионного идентификатора, но не для cookie, которую должен читать клиентский код.

SameSite регулирует отправку cookie в межсайтовом контексте. Значения Lax, Strict и None выбирают по сценарию. Для SameSite=None требуется Secure. Дополнительно проверяют Domain, Path, срок хранения и отсутствие чувствительных данных в открытом значении.

Не каждую cookie без HttpOnly следует автоматически считать ошибкой. Решение зависит от назначения. Внешний наблюдатель может увидеть имя, значение и атрибуты, но не всегда способен достоверно определить роль cookie без документации и доступа к приложению.

Типовые ошибки внешней диагностики

• Проверять только главную страницу, хотя заголовки и ресурсы различаются по разделам.
• Считать любой сертификат достаточным, не проверяя имя домена, срок и цепочку доверия.
• Оценивать CSP по факту наличия, не разбирая разрешенные источники и исключения.
• Объявлять все cookies без одинакового набора атрибутов уязвимыми, не учитывая их назначение.
• Игнорировать ответы после авторизации, отправки формы или выбора региона.
• Смешивать отсутствие рекомендуемого заголовка с подтвержденной эксплуатацией уязвимости.
• Проверять только исходный HTML и не анализировать сетевые запросы после выполнения JavaScript.

Краткий чек-лист

1. Открыть HTTP- и HTTPS-варианты домена, записать всю цепочку ответов.
2. Проверить сертификат для каждого доступного имени хоста.
3. Просмотреть Console и Network на нескольких типах страниц.
4. Найти HTTP-ресурсы и определить, откуда формируются их адреса.
5. Собрать security headers конечного HTML-ответа.
6. Оценить значения HSTS, CSP, правил встраивания, MIME, referrer и permissions.
7. Сопоставить атрибуты cookies с назначением каждой cookie.
8. Повторить наблюдение для важных пользовательских состояний, доступных без административных прав.
9. Разделить подтвержденные признаки, предположения и пункты, требующие внутреннего аудита.

Где заканчиваются возможности метода

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

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

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

Итог

Внешний аудит безопасности сайта разумно начинать с пяти групп признаков: HTTPS и сертификат, перенаправления, mixed content, защитные HTTP-заголовки и атрибуты cookies. Результаты следует формулировать точно: «заголовок отсутствует», «политика разрешает такой источник» или «страница запрашивает ресурс по HTTP», а не делать общий вывод о защищенности всей системы.

SiteVisor анализирует публичный URL без доступа к CMS и помогает собрать технические, SEO/GEO и конверсионные сигналы. Это удобная отправная точка для внешней диагностики, но не замена внутреннему аудиту или тестированию на проникновение. Можно запустить бесплатную проверку SiteVisor, а затем сопоставить наблюдения с ручным чек-листом. Другие практические материалы доступны в блоге SiteVisor.