Есть набор защит, которые браузер включает сам — если сайт его об этом попросит. Просьба — это несколько строк в настройке сервера: заголовки ответа. Они не видны посетителю, не меняют дизайн и ничего не замедляют, но закрывают целые классы атак: подмену соединения, вставку чужого кода, кражу cookie входа, обман через невидимый iframe.
Мы проверили, насколько малый бизнес этими строками пользуется, — и, главное, от чего это на самом деле зависит. Короткий вывод оказался неожиданным: почти всегда защита сайта определяется не решением владельца, а тем, какую платформу он выбрал и что она включает по умолчанию.
Что и как проверяли
- Выборка. 365 сайтов небольших компаний в 19 нишах и шести городах — Москва, Санкт-Петербург, Екатеринбург, Новосибирск, Казань, Краснодар. Ниши новые и разные: частные детские сады, языковые школы, автошколы, юрфирмы, турагентства, доставка цветов, фитнес-клубы, салоны красоты, медцентры, агентства недвижимости и другие. Ответили 345.
- Проверка пассивная. Мы открывали только главную страницу и читали то, что сервер сам отдаёт каждому браузеру: заголовки ответа, флаги cookie, код страницы. Уязвимостей не искали, скрытые адреса не перебирали, ничего не взламывали. Это важно и технически, и юридически: активный поиск дыр на чужом сайте без разрешения владельца — уже статья 272 УК.
- Когда. 10 октября 2026 года, один заход на каждый сайт.
Это измерение гигиены, а не рейтинг уязвимости. Отсутствие заголовка не значит, что сайт взломают завтра, — но значит, что одна из бесплатных защит просто выключена.
HTTPS — у всех. Дальше обрыв
Из 345 сайтов HTTPS работает у 100%. Пять лет назад так было далеко не везде; сейчас шифрованное соединение дают бесплатно и хостинги, и конструкторы. На этом хорошие новости заканчиваются.
Сколько сайтов включили каждую из следующих защит:
- защита от вставки в чужой iframe (X-Frame-Options или CSP) — 33%;
- HSTS (браузер ходит только по HTTPS) — 19%;
- X-Content-Type-Options (браузер не угадывает тип файла) — 13%;
- CSP, политика безопасности содержимого (главная защита от вставки чужого кода) — 7%;
- Referrer-Policy (не утекает адрес страницы) — 7%;
- Permissions-Policy (ограничен доступ скриптов к камере, микрофону, геолокации) — 3%.
Если считать семь базовых защит вместе (HTTPS и шесть заголовков), у половины сайтов — ровно HTTPS и больше ничего. Пять и более защит из семи — у 5%.
Главное: защиту выбирает платформа, а не владелец
Когда мы разложили результат по движкам, картина перестала быть случайной. Три платформы заняли две трети выборки, и у каждой — свой почерк.
Tilda (25% сайтов, самый популярный движок). Защиту от iframe имеют 87% сайтов на Tilda — против 33% в среднем. Не потому, что их владельцы о ней позаботились, а потому что Tilda ставит этот заголовок сама. И наоборот: HSTS и CSP — у 0%, X-Content-Type-Options — у 5%. Чего Tilda не включает, нет вообще ни у кого из её сайтов. Владелец тут ничего не решает: на конструкторе заголовки задаёт платформа, и поменять их из кабинета нельзя. Зато Tilda прячет версию движка — её видно лишь у 5% (против половины в среднем).
WordPress (21%). Своя особенность: 92% сайтов на WordPress открыто показывают свою версию — движок пишет её в коде страницы по умолчанию. Тому, кто перебирает известные дыры конкретной сборки, не нужно её угадывать. Защиту от iframe при этом имеют лишь 6%.
1С-Битрикс (19%). Крепче всех из массовых: HSTS у 30%, CSP у 13%, X-Content-Type-Options у 22% — заметно выше среднего. Причина та же, зеркальная: Битрикс чаще стоит там, где есть администратор, который настраивал сервер руками. Где за сайтом есть инженер, заголовки появляются; где сайт собрали и забыли — нет.
Вывод простой и неуютный: безопасность сайта малого бизнеса — это по большей части то, что досталось от платформы, а не осознанный выбор. Поэтому и выбор платформы — это заодно выбор того, какие защиты у вас будут и сможете ли вы их вообще менять.
Две находки, общие для всех
Cookie без защиты — почти у всех, кто их ставит. Из 238 сайтов, которые устанавливают cookie, у 223 (94%) хотя бы одна cookie идёт без флагов Secure и HttpOnly. Такую cookie можно перехватить на открытом Wi-Fi или прочитать чужим скриптом. Если это cookie входа в админку, чужой скрипт на странице получает доступ к панели. Чаще всего так открыта сессионная cookie движка.
Смешанный контент — у 33%. На защищённой HTTPS-странице подключены файлы по незащищённому HTTP: обычно картинки или скрипты, прописанные ещё до перехода на HTTPS. Браузер их блокирует или ругается, и часть страницы просто не показывается.
Что из этого включается одной строкой
Большая часть защит, если вы на своём сервере, — это настройка по строке на заголовок. Ничего программировать не нужно, дизайн не меняется.
- HSTS —
Strict-Transport-Security: max-age=31536000; includeSubDomains. - Защита от iframe —
X-Frame-Options: SAMEORIGIN. - Тип файла —
X-Content-Type-Options: nosniff. - Referrer —
Referrer-Policy: strict-origin-when-cross-origin. - Права —
Permissions-Policy: geolocation=(), microphone=(), camera=(). - Cookie — флаги
Secure; HttpOnlyсессионной cookie (настройка движка или сервера). - Версия ПО — убрать версию из заголовка
Serverи мета-тега генератора.
Единственная по-настоящему непростая защита — CSP. Её нельзя включить вслепую: список разрешённых источников скриптов собирают под конкретный сайт, иначе ломается то, что грузится со стороны, — карты, аналитика, чаты. Поэтому её и ставят лишь 7%. Это работа на несколько часов, а не одна строка, — но именно CSP закрывает вставку чужого кода, самую частую причину заражения сайтов.
А если сайт на конструкторе — почти ничего из этого вы не включите сами: заголовки задаёт платформа. Тогда проверка полезна в обратную сторону — понять, что именно за вас уже сделано, а что не сделает никто.
Проверить свой сайт
Что видно снаружи, можно посмотреть за минуту: проверка безопасности сайта показывает, какие из этих заголовков у вас включены, нет ли смешанного контента и cookie без флагов, не раскрыта ли версия ПО. Проверка пассивная — читает только то, что сайт отдаёт каждому посетителю.
Важная оговорка: пассивная проверка показывает осанку, но не гарантирует, что сайт не заражён. Вставленный на сервере вредоносный код снаружи виден не всегда. Заражение показывают Google Safe Browsing и Яндекс Вебмастер — проверьте и там.
Если на вашем сайте что-то из этого выключено и хочется закрыть, опишите задачу — посмотрим и скажем, что и за сколько.