Пять настроек безопасности сайта, которые делаются за час

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

HSTS: запрещаем сайту открываться без шифрования

HTTP Strict Transport Security — это заголовок, который говорит браузеру: «заходи на этот домен только по HTTPS, и не спрашивай». Без него есть щель: пользователь набирает адрес без https, первый запрос идёт в открытом виде, и теоретически его можно подменить до редиректа на поддельную страницу.

Добавляется заголовком Strict-Transport-Security: max-age=31536000; includeSubDomains на уровне nginx или в коде сервера. Проверить просто: открыть сайт в браузере, посмотреть вкладку Network в devtools и найти этот заголовок среди ответов сервера.

Осторожность одна: перед включением убедитесь, что HTTPS реально работает на всех поддоменах, которые вы используете — иначе браузер перестанет открывать их до истечения срока в max-age. Директиву preload добавляют только после того, как убедились, что всё стабильно работает хотя бы пару недель.

CSP: ограничиваем, что вообще может выполниться на странице

Content Security Policy — список разрешённых источников для скриптов, стилей, картинок и шрифтов. Если на сайт каким-то образом попадёт чужой JavaScript — через заражённый плагин, скомпрометированную форму или дырявую рекламную вставку — CSP просто не даст ему выполниться, потому что источник не в белом списке.

Начать стоит с мягкого режима Content-Security-Policy-Report-Only, который только логирует нарушения, не блокируя их. Так видно, что сайт реально подгружает — шрифты Google, аналитику, виджет чата — и можно собрать точный список разрешений без риска что-то сломать на живом сайте.

Проверить работу CSP можно в devtools на вкладке Console: браузер прямо пишет, что было заблокировано и почему. Частая ошибка новичков — разрешить inline-скрипты через unsafe-inline, что обесценивает половину смысла политики; лучше вынести скрипты в отдельные файлы или использовать nonce.

Rate-limit: не даём перебирать формы и API бесконечно

Форма входа, форма заявки, API без ограничения на частоту запросов — подарок для ботов, которые перебирают пароли, парсят цены или заливают базу спамом. Rate-limit считает запросы с одного адреса за период и режет лишние, не трогая обычных посетителей.

На nginx это пара строк: limit_req_zone и limit_req в конфиге. На уровне приложения похожий эффект дают готовые пакеты для Express, Fastify и аналогов, настройка занимает минут двадцать. Если сайт за Cloudflare, часть этой работы можно сделать правилами там же, без изменений в коде.

Проверить легко: отправить подряд десяток-два запросов на форму скриптом или просто быстро нажимая кнопку. После настройки сервер должен начать отвечать 429 или таймаутом, а не молча принимать всё подряд.

Бэкапы: проверяем не факт наличия, а факт восстановления

Бэкап, который никогда не разворачивали, порядка в половине случаев не разворачивается, когда это нужно: повреждённый архив, забытый пароль от хранилища, не та версия схемы базы. Это обычная практика любого, кто администрировал сервера дольше года, а не редкое невезение.

Минимум — ежедневный дамп базы и архив файлов с хранением за пределами самого сервера: в облаке или на другой машине. Если сервер физически умрёт, бэкап на нём же не поможет. Держите хотя бы пару последних копий, а не одну — перезапись испорченного бэкапа свежим испорченным не редкость.

Раз в месяц стоит реально восстановить бэкап на тестовом окружении и открыть сайт. Это тот самый час, который окупается, если что-то пойдёт не так, и единственный способ узнать заранее, что архив вообще целый.

Обновления: закрываем дыры, которые уже всем известны

Большинство взломов сайтов идёт не через свежие уязвимости нулевого дня, а через старые, давно описанные дыры в CMS, плагинах и библиотеках, которые просто не обновили. Сканеры ищут именно их, потому что это быстрее и надёжнее, чем искать что-то новое.

Проверка минимальная: зайти в админку CMS и посмотреть список доступных обновлений, или прогнать npm audit либо composer audit, если сайт на своём коде. На серверах с Node или PHP стоит отдельно проверить версию самого языка — она тоже устаревает и перестаёт получать патчи безопасности.

Автоматические обновления удобны, но крупные версии CMS и плагинов иногда ломают вёрстку или интеграции, поэтому их стоит сначала проверять на тестовой копии сайта, а не сразу на рабочей.

Когда делали fortulox.com — лотерею с проверяемыми розыгрышами, где сайт, личный кабинет и админку собрали за два дня — обновления и rate-limit настраивали сразу в процессе, а не постфактум: дешевле сделать правильно один раз, чем потом разбирать инцидент и объяснять пользователям, что случилось.

Пройти все пять пунктов разом дольше, чем кажется из заголовка, но в сумме это один рабочий день, а закрывает почти все типовые автоматические атаки, с которыми реально сталкивается небольшой сайт. Если своего человека под это нет, у нас есть те, кто настраивал такие вещи на боевых проектах вроде vareno.fun и fluxrbot.com.