Содержание9
- Почему владелец должен проверять безопасность сам
- Что проверять: технический чек-лист
- Чем проверять: инструменты для владельца
- Мобильная версия и API: отдельная проверка
- Как часто проверять: расписание аудитов
- Что делать, если сайт уже взломали
- Итог: безопасность как процесс, не разовая проверка
- Частые вопросы
- Источники
Владелец сайта проверяет безопасность в последнюю очередь — после того, как Яндекс вывесил красный экран, клиенты ушли к конкурентам, или пришло письмо от Роскомнадзора. Базовая проверка сайта на безопасность не требует программиста, если знать, на что смотреть. Рассказываем, что проверять, чем проверять и как часто.
Почему владелец должен проверять безопасность сам
Хостинг защищает сервер, но не код вашего сайта. Устаревший плагин, слабый пароль администратора или форма без валидации — это ваша зона ответственности. Когда сайт взломан, хостинг может заблокировать его, чтобы он не заражал соседей по серверу, а восстанавливать приходится вам.
Утечка персональных данных — это требования Роскомнадзора и штрафы по статье 13.11 КоАП, которые растут с масштабом утечки. Плюс простой: пока сайт на карантине, не работает ни приём заявок, ни оплата, ни доставка.
После взлома сайт может оставаться недоступен длительное время. Для интернет-магазина это не только потерянные продажи, но и клиенты, которые не вернутся, потому что увидели предупреждение браузера.
Резервное копирование спасает, только если оно настроено до инцидента. CMS требует регулярного обслуживания: каждое обновление закрывает известные уязвимости, которые уже есть в публичных базах эксплойтов. Ждать, пока хостинг напомнит — значит ждать взлома.
Что проверять: технический чек-лист
SSL-сертификат — первое, что видит браузер. Проверьте срок действия, версию TLS (не ниже 1.2) и корректность редиректа с HTTP на HTTPS. Без HTTPS данные из форм — имя, телефон, почта — передаются открытым текстом.
CMS и плагины обновляйте сразу после выхода патча безопасности. Удалите неиспользуемые темы и модули — они не обновляются, но остаются доступны для вызова. Права на файлы и папки должны быть 644 и 755; 777 — прямой путь к замене любого файла злоумышленником.
WAF — межсетевой экран уровня приложения — защищает от SQL-инъекций и XSS. Если его нет, хотя бы базовую фильтрацию входных данных должен обеспечивать код сайта. Версия PHP должна быть в рамках поддерживаемой ветки: устаревшие версии не получают патчи.
Формы обратной связи и загрузки файлов — частая точка входа. Ограничьте типы загружаемых файлов, проверяйте расширение и MIME-тип, храните загрузки вне корневой директории сайта.
| Пункт | Статус | Чем проверить |
|---|---|---|
| SSL-сертификат: срок, TLS >= 1.2, редирект HTTPS | Критично | SSL Labs, браузер |
| CMS и плагины: актуальные версии | Критично | Админка CMS |
| Права файлов/папок: 644/755, нет 777 | Критично | FTP/SSH, команда ls -la |
| Наличие WAF или фильтрации входных данных | Требует внимания | Sucuri SiteCheck, аудит кода |
| Версия PHP: поддерживаемая ветка | Критично | phpinfo() или хостинг-панель |
| Формы и загрузки: валидация, ограничения типов | Требует внимания | Ручное тестирование |
Чем проверять: инструменты для владельца
Sucuri SiteCheck сканирует сайт извне: малварь, блэклисты, инжекты в код. Не требует установки, работает по URL. Mozilla Observatory оценивает заголовки безопасности и конфигурацию сервера — то, что админы настраивают один раз и забывают проверить.
SSL Labs даёт детальный разбор SSL/TLS-конфигурации: версии протоколов, наборы шифров, цепочку сертификатов. VirusTotal проверяет домен по десяткам антивирусных движков — полезно, если поисковики уже показывают предупреждения.
Яндекс Вебмастер и Google Search Console показывают статус безопасности в поиске. Google Safe Browsing блокирует заражённые сайты на уровне браузера — проверить статус можно до того, как пострадают посетители.
| Инструмент | Что проверяет | Стоимость | Ограничение |
|---|---|---|---|
| Sucuri SiteCheck | Малварь, блэклисты, инжекты | Бесплатно | Только внешнее сканирование |
| Mozilla Observatory | Заголовки безопасности, конфигурация | Бесплатно | Не проверяет код CMS |
| SSL Labs | SSL/TLS-конфигурация | Бесплатно | Технический отчёт, требует интерпретации |
| VirusTotal | Домен по антивирусным движкам | Бесплатно | Не лечит, только диагностирует |
| Яндекс Вебмастер / Google Search Console | Статус в поиске | Бесплатно | Требует подтверждения прав на сайт |
Бесплатных инструментов хватает для базового аудита, но не для полной защиты. Они показывают следствие, а не причину: найдут инжект, но не скажут, через какую уязвимость попали.
Мобильная версия и API: отдельная проверка
Мобильная версия бывает слабее основной, если у неё свои шаблоны или отдельные эндпоинты: проверки, сделанные для десктопа, до них могут не дойти. SQL-инъекция и XSS работают одинаково — независимо от того, с какого устройства пришёл запрос.
API-эндпоинты требуют отдельной проверки: аутентификация по токенам, ограничение числа запросов, логирование обращений. Тестируйте через реальное мобильное устройство, а не только десктопный эмулятор — поведение может отличаться.
Если мобильное приложение работает с тем же бэкендом, уязвимость в API ставит под удар и сайт, и приложение. Проверяйте отдельно, даже если основной сайт прошёл аудит.
Как часто проверять: расписание аудитов
Часть проверок автоматизируется, часть требует человека. Разнесите по расписанию, чтобы не накапливать.
CMS требует резервного копирования как неотъемлемой части обслуживания. Без бэкапа любое обновление — рулетка, а не плановая операция.
Что делать, если сайт уже взломали
Действуйте по порядку, без паники.
Google Safe Browsing блокирует заражённые сайты на уровне браузера — даже после очистки метка сохраняется, пока вы не запросите перепроверку. Не ждите, что она снимется сама.
Итог: безопасность как процесс, не разовая проверка
Если времени на полный аудит нет — начните с трёх приоритетов. SSL-сертификат: проверьте срок и настройку. CMS: обновите всё, что требует обновления. Резервное копирование: убедитесь, что копии делаются, и разверните одну для проверки.
Когда самостоятельно не справиться: сайт на самописной CMS без документации, следы взлома в ядре системы, необходимость интеграции WAF или регулярный пентест для соответствия требованиям платёжных систем. Сложный аудит безопасности — задача для специалистов: регулярные обновления, бэкапы и контроль уязвимостей входят в техническую поддержку сайта.
