Как проверить безопасность сайта самостоятельно: 15 пунктов
Вы не обязаны быть экспертом по кибербезопасности, чтобы оценить базовый уровень защищённости вашего сайта. Большинство взломов происходит не из-за сложных хакерских атак, а из-за элементарных ошибок: открытых служебных файлов, устаревшего ПО, слабых паролей. В этой статье — практический чеклист из 15 пунктов, которые можно проверить самостоятельно за 30–40 минут. Для каждого пункта указано, что проверять, как проверять и что делать, если нашли проблему.
Блок 1. SSL и заголовки безопасности
1. SSL-сертификат и HTTPS
Откройте сайт в браузере и посмотрите на адресную строку. Если видите замок — HTTPS работает. Если нет — данные между сайтом и посетителями передаются в открытом виде. Также проверьте, что HTTP-версия сайта перенаправляет на HTTPS — введите адрес без https:// и убедитесь, что происходит редирект.
Как проверить глубже: откройте SSL Labs и введите адрес сайта. Оценка A или A+ — хорошо. B — допустимо, но стоит улучшить. C и ниже — есть проблемы с конфигурацией SSL.
2. Заголовки безопасности
HTTP-заголовки безопасности — это инструкции, которые сервер отправляет браузеру: какой контент разрешено загружать, можно ли встраивать сайт в iframe, как обрабатывать cookies. Без них сайт уязвим для целого класса атак.
Как проверить: откройте securityheaders.com и введите адрес сайта. Ключевые заголовки, которые должны быть настроены:
- Content-Security-Policy (CSP) — ограничивает, откуда браузер может загружать скрипты, стили и другие ресурсы. Главная защита от XSS-атак
- X-Frame-Options — запрещает встраивание сайта в iframe на чужих ресурсах. Защита от clickjacking
- X-Content-Type-Options — запрещает браузеру «угадывать» тип файла. Должен быть установлен в nosniff
- Strict-Transport-Security (HSTS) — принуждает браузер использовать только HTTPS
- Permissions-Policy — ограничивает доступ к API браузера (камера, микрофон, геолокация)
Блок 2. Открытые данные и служебные файлы
3. Файл .env
Файл .env содержит конфигурацию приложения: пароли от базы данных, ключи API, секреты. Если он доступен через браузер — это критическая уязвимость.
Как проверить: откройте в браузере ваш-сайт.ru/.env — если видите содержимое файла с переменными вроде DB_PASSWORD или API_KEY, немедленно закройте доступ через настройки веб-сервера и смените все скомпрометированные пароли и ключи.
4. Директория .git
Если на сервере осталась папка .git, злоумышленник может скачать весь исходный код сайта, включая конфигурационные файлы с паролями.
Как проверить: откройте ваш-сайт.ru/.git/config — если видите содержимое, папка доступна извне. Закройте доступ к .git через конфигурацию nginx или .htaccess.
5. Резервные копии и дампы
Разработчики иногда оставляют на сервере файлы бэкапов: dump.sql, backup.zip, site.tar.gz, db.sql.gz. Если они доступны по прямой ссылке — злоумышленник получит полную копию сайта и базы данных.
Как проверить: попробуйте открыть типичные адреса: /backup.zip, /dump.sql, /db.sql, /site.tar.gz, /bitrix/backup/. Если что-то скачивается — немедленно удалите файлы с сервера.
6. Панели администрирования
Стандартные URL админ-панелей известны всем — и хакерам тоже. Автоматические сканеры первым делом проверяют /wp-admin/, /bitrix/admin/, /administrator/, /admin/.
Как проверить: попробуйте открыть стандартный URL админки вашей CMS. Если он доступен без ограничений — настройте фильтрацию по IP-адресу и ограничение попыток входа.
7. Листинг директорий
Если веб-сервер настроен с включённым autoindex, любой может увидеть список файлов в директориях сайта.
Как проверить: откройте ваш-сайт.ru/upload/ или другую директорию без index-файла. Если видите список файлов — отключите листинг в настройках nginx (autoindex off) или Apache (Options -Indexes).
Блок 3. CMS и серверное ПО
8. Версия CMS
Устаревшая версия CMS — самая частая причина взломов. Каждое обновление закрывает найденные уязвимости, а хакеры целенаправленно ищут сайты на старых версиях.
Как проверить: зайдите в админ-панель и посмотрите текущую версию. Сравните с последней доступной на сайте разработчика. Для Битрикс — проверьте в Настройки → Обновление системы. Для WordPress — в Консоль → Обновления.
9. Плагины и модули
Неиспользуемые и устаревшие плагины — это мёртвый код с потенциальными уязвимостями. Каждый плагин увеличивает поверхность атаки.
Как проверить: откройте список установленных модулей в админке. Удалите всё, что не используется. Обновите всё, что используется.
10. Версия PHP
Старые версии PHP (5.x, 7.0–7.3) больше не получают обновлений безопасности. Работа на неподдерживаемой версии PHP означает, что известные уязвимости интерпретатора никогда не будут закрыты.
Как проверить: в админ-панели Битрикс — Настройки → Производительность → PHP. В WordPress — через плагин или страницу Здоровье сайта. Минимальная рекомендуемая версия в 2026 году — PHP 8.1.
Блок 4. DNS и почта
11. SPF-запись
SPF указывает, какие серверы имеют право отправлять почту от имени вашего домена. Без неё злоумышленники могут рассылать фишинговые письма якобы с вашего адреса.
Как проверить: откройте mxtoolbox.com/spf.aspx и введите домен. Если SPF-записи нет или она настроена с ошибками — исправьте через DNS-панель хостинга.
12. DKIM и DMARC
DKIM подписывает исходящие письма цифровой подписью. DMARC определяет политику обработки писем, не прошедших проверку SPF и DKIM. Вместе они защищают вашу почту и клиентов от фишинга.
Как проверить: на том же mxtoolbox.com проверьте DKIM Lookup и DMARC Lookup для вашего домена.
Блок 5. Доступы и пароли
13. Двухфакторная аутентификация
Если для входа в админку, хостинг, SSH достаточно только пароля — учётная запись уязвима для brute-force атак и фишинга. Двухфакторная аутентификация (2FA) добавляет второй уровень защиты — даже если пароль украден, без второго фактора войти не получится.
Как проверить: зайдите в настройки безопасности хостинга, админ-панели CMS, SSH. Если 2FA не включена — включите. Используйте приложения-аутентификаторы, а не SMS.
14. Список пользователей с доступом
Бывшие сотрудники, подрядчики, фрилансеры — у всех ли отозваны доступы? Оставленный активным аккаунт уволенного разработчика — это открытая дверь.
Как проверить: просмотрите список пользователей в админ-панели, на хостинге, в FTP/SSH. Удалите или заблокируйте все неактуальные учётные записи.
15. Надёжность паролей
Пароль admin123 подбирается за секунды. Пароль из 16+ символов с буквами, цифрами и спецсимволами — за годы.
Как проверить: если вы можете вспомнить пароль от админки наизусть — он, скорее всего, недостаточно сложный. Используйте менеджер паролей (Bitwarden, 1Password) и генерируйте уникальные пароли для каждого сервиса.
Что делать с результатами
Если по итогам проверки вы нашли 1–2 проблемы в DNS или заголовках — это можно исправить самостоятельно. Если обнаружились открытые .env файлы, устаревшая CMS или отсутствие 2FA — ситуация серьёзнее и требует комплексного подхода.
Этот чеклист покрывает базовые проверки, которые может выполнить любой владелец сайта. Но профессиональный аудит идёт значительно глубже: ручное тестирование на SQL-инъекции, XSS, SSRF, проверка бизнес-логики, анализ исходного кода и архитектуры, поиск по базам известных уязвимостей CVE для каждого установленного компонента.
Если хотите получить полную картину безопасности вашего сайта — закажите профессиональный аудит. А если проблемы уже привели к инциденту — мы поможем восстановить сайт и закрыть уязвимости.