Как проверить сайт на уязвимости: пошаговый гайд
Взлом сайта — это редко «случайность». Чаще всего это результат накопленных мелочей: устаревший плагин, открытый файл конфигурации, пароль admin123 или форма без серверной валидации. Аудит безопасности помогает найти эти бреши до того, как их обнаружат боты или конкуренты.
Что именно проверять
1. Поверхностные уязвимости (Low-hanging fruits)
- Открытые
.env,wp-config.php,.git,composer.json - Стандартные логины (
admin,root,test) - Формы без rate-limit и защиты от CSRF
- Публичные бэкапы или дампы БД
2. Уязвимости компонентов
- Версии CMS, плагинов, тем, фреймворков
- Известные CVE в зависимостях (npm, composer, pip)
- Сторонние скрипты (виджеты чатов, аналитика, карты)
3. Серверная и сетевая безопасность
- Настройки TLS/SSL (поддержка TLS 1.2+, отключение старых протоколов)
- Заголовки безопасности:
Content-Security-Policy,X-Frame-Options,X-Content-Type-Options - Ограничение доступа к
/admin,/wp-login,/bitrix/adminпо IP или 2FA - Права на файлы:
644для файлов,755для директорий
Инструменты для проверки
| Задача | Инструмент |
|---|---|
| Сканирование CMS | WPScan (WordPress), Droopescan (Drupal), nuclei (универсальный) |
| Поиск XSS/SQLi/открытых редиректов | OWASP ZAP, Burp Suite Community, Nikto |
| Проверка заголовков и SSL | SecurityHeaders.com, SSL Labs Test |
| Анализ зависимостей | npm audit, composer audit, pip-audit |
| Мониторинг изменений | File integrity monitoring (AIDE, OSSEC), лог-агрегаторы |
⚠️ Важно: автоматические сканеры находят ~30–40% проблем. Остальное выявляется только ручным аудитом и анализом бизнес-логики.
Чек-лист регулярного аудита
- Обновить CMS, плагины, темы, серверное ПО
- Удалить неиспользуемые модули и старые бэкапы из публичного доступа
- Включить 2FA для всех администраторов и редакторов
- Проверить формы на rate-limit, honeypot и серверную валидацию
- Просканировать сайт через 2–3 независимых инструмента
- Проверить логи сервера на аномальные запросы (
/wp-admin,/admin.php,xmlrpc.php) - Настроить автоматические уведомления о входах и изменении файлов
Когда аудит обязателен
- После запуска новой версии или интеграции
- При смене хостинг-провайдера или миграции
- Раз в квартал для коммерческих проектов
- Немедленно при подозрении на взлом (подозрительные редиректы, спам в почте, рост нагрузки)
Итог
Безопасность — не разовое мероприятие, а процесс. Начните с закрытия очевидных дыр, подключите мониторинг и проводите аудит по расписанию. Если у вас нет выделенного DevSecOps-инженера, делегируйте задачу специалистам: дешевле настроить защиту сейчас, чем восстанавливать репутацию и данные потом.
Если вы не уверены в безопасности проекта — можно проверить сайт с полным аудитом и рекомендациями по устранению.