Как проверить безопасность сайта: HTTPS, TLS и защитные заголовки

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

Что показывает экспресс-проверка сайта

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

• открывается ли сайт по HTTPS и перенаправляет ли HTTP на защищенный адрес;
• действителен ли TLS-сертификат и совпадает ли доменное имя;
• включены ли защитные HTTP-заголовки;
• не загружается ли активный контент по незащищенному HTTP;
• имеют ли cookies признаки Secure, HttpOnly и подходящий SameSite;
• не передается ли пароль через форму без защищенного соединения;
• не раскрывает ли сервер лишние сведения о технологии и версии.

Это полезная первая линия контроля, но не полноценный пентест. Она не подтверждает отсутствие SQL-инъекций, ошибок авторизации, уязвимостей бизнес-логики или проблем внутри закрытого кабинета.

HTTPS и TLS — не одно и то же

HTTPS означает, что обмен данными идет через защищенное соединение. TLS-сертификат подтверждает домен и участвует в шифровании. Зеленый замок в браузере важен, но для нормальной конфигурации нужно проверить несколько условий одновременно.

Сертификат должен быть действующим, выданным для нужного домена и собираться в доверенную цепочку. Сайт по HTTP должен перенаправлять пользователя на HTTPS, причем без промежуточного возврата на незащищенный адрес. Желательно заранее отслеживать срок действия сертификата: посетитель заметит проблему только в день отказа, а мониторинг предупредит раньше.

Какие защитные заголовки важны

HTTP-заголовки задают браузеру дополнительные правила. Они не заменяют исправный код приложения, но уменьшают последствия ряда ошибок.

Strict-Transport-Security

Strict-Transport-Security, или HSTS, сообщает браузеру, что домен нужно открывать только по HTTPS. Заголовок имеет смысл после того, как защищенная версия сайта работает стабильно на всех нужных поддоменах. Ошибочное включение HSTS с большим сроком может затруднить откат, поэтому настройку вводят осознанно.

Content-Security-Policy

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

Защита от встраивания и определения MIME-типа

frame-ancestors в CSP или устаревший X-Frame-Options помогают защитить страницу от нежелательного встраивания в iframe. X-Content-Type-Options: nosniff запрещает браузеру угадывать тип содержимого там, где это может быть опасно.

Referrer-Policy и Permissions-Policy

Referrer-Policy управляет тем, какая часть адреса передается другому сайту при переходе. Permissions-Policy ограничивает доступ страницы и встроенных элементов к возможностям браузера: камере, микрофону, геолокации и другим API. Нужные значения зависят от функций сайта, поэтому проверка должна давать рекомендацию, а не бездумно требовать один шаблон для всех.

Проверьте cookies, формы и смешанный контент

Сессионные cookies обычно должны иметь флаг Secure, чтобы не передаваться по HTTP, и HttpOnly, чтобы клиентский JavaScript не мог прочитать их напрямую. SameSite помогает ограничить отправку cookies в межсайтовых запросах. Конкретный режим выбирают с учетом авторизации и внешних интеграций.

Смешанный контент появляется, когда HTTPS-страница загружает скрипт, стиль, iframe или другой активный ресурс по HTTP. Браузер может заблокировать такой ресурс, а пользователь увидит сломанную страницу. Особенно внимательно стоит проверять старые шаблоны, счетчики и внешние виджеты.

Форма с паролем не должна отправляться через HTTP. Также важно исключить пароль из адресной строки: параметры URL попадают в историю браузера, журналы и аналитику.

Почему одной проверки недостаточно

Сегодня заголовок настроен правильно, а завтра его может убрать новая конфигурация reverse proxy. Сертификат действует сейчас, но закончится через несколько недель. Внешний вид сайта при этом долго остается обычным, поэтому проблема обнаруживается слишком поздно.

Постоянный мониторинг решает другую задачу, чем разовая проверка. Он запускает аудит по расписанию, сохраняет дату и результат, сравнивает состояние с предыдущим запуском и показывает новые или исправленные замечания. Для агентства это еще и доказательство регулярного контроля проекта.

Как читать итоговую оценку

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

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

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

Как организовать контроль в RepWay

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

В платных тарифах мониторинг привязывается к рабочему пространству и конкретному проекту. Перед регулярными запусками владелец подтверждает управление доменом через DNS-запись или проверочный файл. Это не позволяет использовать систему как бесконтрольный сканер чужих ресурсов. Частота и количество сайтов зависят от тарифа RepWay.

Завершенный результат можно добавить в мастер отчетов. В публикацию попадает зафиксированный снимок: оценка, дата, HTTPS, найденные замечания и рекомендации. Последующие проверки не переписывают уже отправленный заказчику отчет.

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

1. Проверьте перенаправление с HTTP на HTTPS.
2. Убедитесь, что TLS-сертификат действителен для нужного домена.
3. Проверьте HSTS, CSP, защиту от iframe и nosniff.
4. Просмотрите Referrer-Policy и Permissions-Policy.
5. Найдите смешанный активный контент.
6. Проверьте флаги cookies и отправку форм с паролями.
7. Уберите лишнее раскрытие технологий и версий.
8. Повторите аудит после исправлений.
9. Настройте регулярный мониторинг, если сайт важен для заявок или работы заказчика.

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