Аудит безопасности сайта: чек-лист из 12 пунктов

9 июля 2026 · Команда SaitHub · Безопасность

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

Почему это важно именно сейчас: в 2026 году атаки на небольшие сайты почти полностью автоматизированы. Боты круглосуточно сканируют рунет, находят WordPress с плагином трёхлетней давности или открытый дамп базы в корне сайта — и эксплуатируют дыру за минуты. Взламывают не «кого-то выбрали», а «кого нашёл сканер». Поэтому вопрос не «интересен ли мой сайт хакерам», а «сколько известных уязвимостей на нём висит прямо сейчас». Средний ущерб от взлома для малого бизнеса — от 150 000 до 1,5 млн рублей: простой, восстановление, потерянные заказы и просевшие позиции в поиске. Ниже — 12 пунктов, отсортированных от простого к сложному, с пояснением, что именно проверять, чем и какой риск закрывает каждый пункт.

Базовый уровень (проверяется за час)

1. HTTPS на всех страницах, HTTP отдаёт 301-редирект. Что проверять: откройте сайт по http:// — должен быть мгновенный редирект на https://, без «смешанного контента» (картинки и скрипты тоже по HTTPS). Чем: браузер + сервис SSL Labs (оценка не ниже A). Риск: без HTTPS трафик перехватывается в открытых Wi-Fi-сетях, браузеры помечают сайт как «небезопасный», а поисковики занижают позиции. Проверьте и срок сертификата — просроченный SSL за одну ночь роняет конверсию до нуля.
2. Админ-панель не открывается без пароля и не «спрятана» только через robots.txt. Что проверять: наберите /admin, /wp-admin, /bitrix, /administrator — форма входа не должна быть доступна всему интернету без ограничений. Чем: вручную плюс просмотр логов на предмет перебора. Риск: открытая админка — цель номер один для брутфорса; боты перебирают тысячи паролей в час. Минимум — ограничение по IP или второй фактор, максимум — вынос панели на отдельный поддомен за VPN.
3. Пароли уникальные и в менеджере паролей; включена двухфакторка везде, где есть. Что проверять: нет ли пароля «как у почты», не лежит ли доступ в общем чате или Excel-файле «Пароли.xlsx». Чем: опрос команды и проверка утечек по базе haveibeenpwned. Риск: один слитый пароль от стороннего сервиса открывает и хостинг, и админку, и почту домена — а через почту сбрасываются все остальные доступы.
4. CMS, плагины и библиотеки обновлены. Что проверять: версию ядра CMS, каждого плагина и JS-зависимостей; версии с известными CVE — под замену в первую очередь. Чем: встроенный менеджер обновлений, WPScan для WordPress, composer audit / npm audit для кода. Риск: по статистике, уязвимые плагины и темы — причина более половины взломов CMS-сайтов. Эксплойты к популярным дырам публикуются через считанные дни после патча.
5. Резервные копии делаются автоматически и — главное — хотя бы раз восстанавливались. Что проверять: где лежат бэкапы (не на том же сервере!), как часто создаются, когда последний раз тестировали восстановление. Чем: попробуйте развернуть вчерашнюю копию на тестовом поддомене — это займёт час и ответит на все вопросы. Риск: бэкап, который никогда не разворачивали, — это лотерея. При взломе или шифровальщике рабочая копия — разница между простоем в 2 часа и потерей бизнеса.

Средний уровень (нужен доступ к серверу)

6. Заголовки безопасности: HSTS, X-Content-Type-Options, Content-Security-Policy. Что проверять: ответ сервера на главной странице. Чем: сервис securityheaders.com или curl -I. Риск: без HSTS возможна атака с понижением до HTTP, без CSP — внедрение чужих скриптов, ворующих данные из форм. Настройка занимает 30–60 минут в конфиге Nginx и не требует изменений в коде.
7. Формы защищены от инъекций: параметризованные запросы к БД, экранирование вывода. Что проверять: все места, где пользовательский ввод попадает в SQL-запрос или выводится на страницу — поиск, фильтры, комментарии, личный кабинет. Чем: базово — подстановка кавычки ' и тега <script> в поля; серьёзно — сканеры sqlmap и OWASP ZAP на тестовой копии. Риск: SQL-инъекция отдаёт злоумышленнику всю базу с клиентами и заказами, XSS — крадёт сессии администраторов.
8. Загрузка файлов ограничена по типу и размеру, файлы проверяются по содержимому, а не по расширению. Что проверять: формы загрузки аватаров, резюме, документов. Попробуйте загрузить файл shell.php.jpg — если сервер его принял и исполняет, это критическая дыра. Риск: загруженный веб-шелл даёт полный контроль над сайтом; каталог загрузок должен быть закрыт от исполнения скриптов на уровне сервера.
9. Секреты (ключи API, пароли БД) не лежат в коде и репозитории — только в переменных окружения. Что проверять: историю git на предмет закоммиченных .env, доступность файлов конфигурации по прямым URL (/.env, /config.php.bak). Чем: gitleaks по репозиторию, curl по типовым путям. Риск: .env в вебруте индексируется сканерами за часы — вместе с ним утекают пароль БД и ключи платёжных систем. Сюда же — забытые дампы и архивы: /backup.zip, /db.sql в корне сайта находят так же быстро.
10. Права доступа минимальны: сервисы не работают из-под root, у сотрудников нет «общего админа». Что проверять: под каким пользователем крутится PHP/Node, какие права на каталогах (директории 755, файлы 644, конфиги с паролями — 600), у кого из бывших сотрудников остались доступы. Риск: если сайт работает из-под root, любая мелкая дыра в плагине превращается в захват всего сервера. А «общая учётка» лишает вас возможности понять по логам, кто и что сделал.

Продвинутый уровень

11. Логи собираются централизованно, по подозрительным событиям есть алерты. Что проверять: пишутся ли логи входов в админку, ошибок 4xx/5xx и изменений файлов; узнаете ли вы о взломе раньше, чем клиенты. Чем: fail2ban против перебора, мониторинг целостности файлов (AIDE или встроенные средства панели), алерты в Telegram. Риск: по данным отраслевых отчётов, взлом в среднем замечают через недели — всё это время сайт рассылает спам, майнит или отдаёт клиентские данные.
12. Раз в год — внешний пентест: свежий взгляд находит то, к чему внутри уже привыкли. Что проверять: бизнес-логику (можно ли изменить цену в заказе, посмотреть чужой личный кабинет), связки уязвимостей, которые сканер не видит. Чем: ручной пентест по методологии OWASP с отчётом и ретестом. Риск: автоматика находит типовое, но обход оплаты или доступ к чужим заказам — это всегда ручная работа. Именно такие дыры стоят дороже всего.

Сводная таблица: типовые уязвимости и как их проверить

Мини-кейс: во что обошёлся один необновлённый плагин

Интернет-магазин автозапчастей из Казани, около 900 заказов в месяц, WordPress + WooCommerce. В плагине слайдера, который не обновляли два года, была публично известная уязвимость. Бот нашёл её сканированием, загрузил веб-шелл и встроил в страницу оплаты скиммер, копировавший данные карт. Заметили не сразу — через 11 дней, когда эквайринг заблокировал приём платежей из-за жалоб покупателей.

Итог в цифрах: 3 дня полного простоя на очистку и переустановку — около 270 000 ₽ недополученной выручки; работа подрядчика по разбору инцидента и восстановлению — 90 000 ₽; уведомление клиентов и работа с претензиями — ещё около 60 000 ₽ и часть постоянных покупателей. Совокупно инцидент стоил больше 400 000 ₽. Обновление плагина заняло бы две минуты, а полный аудит по этому чек-листу — один рабочий день. После инцидента магазин перешёл на регулярную поддержку с ежемесячными обновлениями — за полтора года ни одного повторного взлома.

Что делать после аудита

Список найденных проблем сам по себе ничего не меняет — важен порядок работ. Рекомендуем такой план:

1. Приоритизация по риску. Сначала критичное: всё, что эксплуатируется удалённо без авторизации (инъекции, открытые дампы, дефолтные пароли) — закрывается в первые 24–48 часов. Затем высокий уровень (устаревшее ПО, отсутствие 2FA) — в течение недели. Средний и низкий (заголовки, косметика конфигов) — в течение месяца.
2. Патчи и обновления. Обновляйте сначала на тестовой копии, потом на бою — мажорные обновления CMS иногда ломают шаблоны. Перед обновлением — свежий бэкап. Плагины, которые не обновлялись автором больше года, лучше заменить на живые аналоги.
3. Устранение корневых причин. Если пароли утекали — внедрите менеджер паролей и 2FA для всей команды, а не просто смените один пароль. Если секреты были в коде — настройте переменные окружения и проверку в CI.
4. Мониторинг. Настройте алерты на входы в админку с новых IP, изменение файлов ядра, всплески 500-х ошибок и окончание срока SSL. Минимальный набор — fail2ban плюс уведомления в Telegram — настраивается за пару часов и стоит ноль рублей.
5. Регулярность. Внесите в календарь: обновления — ежемесячно, прогон этого чек-листа — ежеквартально, внешний аудит или пентест — ежегодно и после каждого крупного релиза.

Отдельный совет: безопасность стоит проверять в связке с общим техническим состоянием сайта. Медленные страницы, битые ссылки и хаос в коде часто соседствуют с дырами в защите — комплексный технический аудит сайта закрывает обе задачи за один заход.

Частые вопросы

Чем аудит безопасности отличается от пентеста?

Аудит — это систематическая проверка по списку: конфигурация, версии ПО, права, пароли, заголовки. Он отвечает на вопрос «что у нас настроено неправильно». Пентест — имитация реальной атаки: специалист пытается взломать сайт как злоумышленник и отвечает на вопрос «что реально можно сломать и как далеко зайти». На практике сначала делают аудит и закрывают очевидное, потом пентест проверяет остальное.

Сколько стоит аудит и как долго он длится?

Базовый аудит безопасности сайта на CMS — от 30 000 до 80 000 ₽ и 3–7 рабочих дней. Полный пентест веб-приложения с ручной проверкой бизнес-логики — от 120 000 до 400 000 ₽ и 2–4 недели в зависимости от размера проекта. На выходе — отчёт с уязвимостями по степени критичности и конкретным планом исправлений, а после устранения — бесплатный ретест.

Как часто проводить проверку безопасности?

Самостоятельный прогон чек-листа — раз в квартал и после любых крупных изменений: переезд на новый хостинг, установка плагинов, запуск личного кабинета или оплаты. Внешний аудит или пентест — раз в год. Если сайт принимает платежи или хранит персональные данные, регулярные проверки — это ещё и требование банков-эквайеров и 152-ФЗ.

Что такое OWASP Top 10?

Это регулярно обновляемый список десяти самых распространённых классов уязвимостей веб-приложений, который ведёт международное сообщество OWASP: инъекции, нарушения контроля доступа, небезопасная конфигурация, устаревшие компоненты и другие. Де-факто это отраслевой стандарт: серьёзные аудиты и пентесты строятся вокруг него, а фраза «проверка по OWASP Top 10» в коммерческом предложении — признак того, что подрядчик работает по методологии, а не «просто посмотрит».

Можно ли провести аудит самостоятельно?

Базовый уровень — да, и нужно: пункты 1–5 из этого чек-листа проходятся за вечер без специальных знаний и закрывают самые массовые векторы атак. Средний уровень потребует доступа к серверу и базовых навыков администрирования. А вот инъекции, бизнес-логику и связки уязвимостей надёжно проверяет только специалист — самостоятельный запуск сканеров без понимания результатов даёт ложное чувство защищённости.