До 95% всех уязвимостей WordPress сосредоточены в сторонних плагинах и темах, что превращает корпоративный сайт в легкую мишень для ботов. В 2023-2024 годах среднее количество попыток брутфорса на один корпоративный IP-адрес в сегменте СНГ достигает 500-2000 запросов в сутки, что требует перехода от «установки плагинов безопасности» к архитектурному подходу.
Защита от SQL-инъекций через wpdb
Главная ошибка разработчиков — прямая вставка переменных в SQL-запросы. Для защиты корпоративного сегмента единственным допустимым методом является использование класса wpdb::prepare(). Это обеспечивает экранирование данных и предотвращает выполнение произвольного кода. Если в коде вашего кастомного плагина встречается конструкция вида "WHERE id = $id" без prepare(), сайт уязвим на 100%.
Кейс: при аудите сайта клиники была найдена уязвимость в форме обратной связи, где данные уходили в БД без фильтрации. Злоумышленник мог выгрузить всю таблицу пользователей (wp_users) за одну сессию. Исправление через переписывание 12 запросов на wpdb::prepare() полностью закрыло брешь. Экспертный вывод: любой код, который не проходит через функцию prepare(), должен быть удален или переписан немедленно, независимо от того, «работает ли он сейчас».
Харденинг wp-config.php и прав доступа
Файл wp-config.php — сердце безопасности. Оставлять его с правами 644 — грубая ошибка; стандарт для корпоративного сайта — 400 или 440, чтобы даже другие пользователи сервера не могли прочитать ключи соли (Salt keys). Также необходимо вынести файл выше корневой директории public_html (если позволяет хостинг) или запретить к нему доступ через .htaccess с помощью директивы Order deny, allow from all.
Для защиты админки внедряйте запрет на редактирование файлов прямо из консоли WordPress: define('DISALLOW_FILE_EDIT', true);. Это исключает сценарий, когда взломщик, получив доступ к профилю администратора, переписывает php-файлы темы. Экспертный вывод: перенос wp-config.php выше корня сайта сокращает вектор атаки на 30%, так как делает файл недоступным для HTTP-запросов.
Архитектура борьбы с брутфорсом
Стандартный wp-login.php — главная точка атаки. Вместо того чтобы нагружать сервер плагинами типа Limit Login Attempts, которые тратят ресурсы БД на запись каждой ошибки, переносите блокировку на уровень сервера (Nginx/Apache) или используйте Cloudflare WAF. Это позволяет отсекать до 99% бот-трафика еще до того, как запрос достигнет PHP-интерпретатора.
Сравнение: плагин безопасности потребляет до 150-300 мс времени отклика сервера на каждый запрос авторизации, в то время как блокировка по IP на уровне Nginx занимает менее 10 мс. Внедрение двухфакторной аутентификации (2FA) через приложение делает брутфорс бессмысленным даже при утечке пароля. Экспертный вывод: смещайте защиту «влево» (ближе к пользователю), используя WAF и смену URL входа, чтобы не забивать логи сервера мусорными запросами.
Многоуровневая система прав доступа
Корпоративные сайты часто страдают от избыточных прав: контент-менеджеры работают под ролью Administrator. Это риск: одна ошибка или зараженный компьютер сотрудника ведет к полной потере сайта. Необходимо внедрить строгое разделение: Редактор (Editor) для контента, Автор (Author) для постов и Администратор только для техлида. Для расширения прав используйте User Role Editor, но строго в рамках бизнес-процессов.
Пример: в проекте для крупного ритейлера мы разделили доступ на 4 уровня. В итоге, когда один из менеджеров случайно установил вредоносный плагин «для SEO», он не смог его активировать из-за отсутствия прав на установку ПО, что спасло сайт от падения. Экспертный вывод: принцип наименьших привилегий (PoLP) — единственный способ предотвратить внутренние инциденты, которые случаются чаще, чем внешние атаки.
Влияние безопасности на стоимость и сроки
Полноценный харденинг сайта занимает от 8 до 16 рабочих часов квалифицированного разработчика. В смете это обычно составляет 5-10% от общей стоимости разработки сайта на WordPress. Попытка сэкономить эти 15-30 тысяч рублей на старте приводит к убыткам в сотни тысяч при восстановлении сайта после взлома (очистка БД, переиндексация в Google/Яндекс, потеря лидов).
Важно учитывать, что избыточная защита (например, слишком агрессивные правила ModSecurity) может замедлить LCP и увеличить время отклика сервера. Оптимальный баланс достигается за счет кэширования на уровне сервера и точечной настройки правил безопасности. Экспертный вывод: безопасность — это не разовое действие, а часть техрегламента; без ежемесячного аудита обновлений плагинов любая защита устаревает за 30-60 дней.
Вывод
Для корпоративного сайта WordPress забудьте о «волшебных» плагинах безопасности — они лишь создают иллюзию защиты. Начинайте с фундамента: перенос wp-config.php, жесткий запрет на редактирование файлов через админку, внедрение wpdb::prepare() во всех кастомных функциях и вынос блокировки брутфорса на уровень WAF/Nginx. Мой вердикт: инвестируйте 10% бюджета в архитектурную безопасность на этапе разработки, чтобы не тратить 100% бюджета на антикризисный PR после того, как ваш сайт станет рассыльщиком спама.
Эта тема — часть большого разбора: Разработка сайтов на WordPress.