О проблемах с безопасностью владелец магазина обычно узнаёт одним из двух способов: звонком от хостинга «на вашем сайте вредоносный код» или жалобой клиента, с карты которого списались деньги уже после оплаты на сайте. Третий вариант, к сожалению, встречается редко – взлом почти никогда не выглядит как всплывающее окно с черепом и костями. Чаще это просто чуть более медленный сайт, странная папка в /wp-content/uploads с php-файлами и позиции в Google, которые тихо сползают вниз, потому что магазин без ведома владельца раздаёт ссылки на казино или серую фарму.
Сам WordPress не дырявый движок. Дырявыми обычно оказываются плагины, темы и привычки администратора. Разберём, где именно магазины на WooCommerce чаще всего ломаются – и что с этим реально делать, без общих советов «обновляйте всё вовремя».
Устаревшие плагины и темы – самый популярный вход
На сайтах, которые уже взломали, картина часто знакомая: старый слайдер, брошенный шаблон с нулевого маркетплейса, или плагин-калькулятор доставки, который автор перестал обновлять три года назад. Уязвимость публикуют в базе вроде WPScan – и через пару дней боты уже сканируют сеть в поисках сайтов с такой же версией плагина.
Это значит: раз в неделю – проверка списка плагинов на «требует обновления», удаление всего неиспользуемого (деактивированный плагин – тот же код на диске, он так же уязвим), и отдельное внимание к нулёванным темам и плагинам. Пиратская версия платного плагина почти всегда содержит бэкдор, вшитый тем, кто её «взломал» – это не городская легенда, а типичная находка при чистке заражённых сайтов.
Слабый пароль администратора и отсутствие двухфакторки
Логин admin и пароль вроде названия магазина плюс 2026 – до сих пор не редкость. Брутфорс-боты перебирают именно такие комбинации тысячами в час, и им не нужен ум, нужно только время.
- Сменить логин администратора с admin на что-то неочевидное – завести отдельного пользователя, старого удалить или понизить в правах.
- Включить двухфакторную аутентификацию – плагины Wordfence Login Security или miniOrange 2FA настраиваются за 10 минут.
- Ограничить количество попыток входа – Limit Login Attempts Reloaded или аналогичная функция в security-плагине.
Отдельная история – пароли сотрудников с доступом к админке или FTP. Один слабый пароль менеджера, который заводит товары в каталог, сводит на нет всю остальную защиту.
Формы загрузки файлов без ограничений
Форма «Загрузить фото к отзыву» или «Прикрепить файл к заявке на возврат» – удобная вещь для клиента. Но если плагин или кастомный код не проверяет расширение файла, а сервер разрешает выполнять PHP в папке uploads, злоумышленник загружает не фото, а веб-шелл – маленький php-файл, который даёт полный контроль над сайтом через обычный браузер.
Закрывается это на двух уровнях. На уровне плагина – белый список разрешённых расширений (jpg, png, pdf), а не чёрный список запрещённых. На уровне сервера – запрет выполнения PHP в /wp-content/uploads/ через правило в .htaccess или конфиг Nginx. Пять минут работы, которые закрывают целый класс атак.
wp-config.php, debug-режим и чужие глаза
Файл wp-config.php хранит пароли от базы данных открытым текстом. Он вообще не должен быть доступен извне, но случается, что после неудачного переноса сайта или бэкапа появляется wp-config.php.bak или wp-config.php~ – а такие файлы сервер отдаёт как обычный текст, а не выполняет как PHP.
Второй момент – режим WP_DEBUG, оставленный включённым на боевом сайте «чтобы увидеть ошибку». Он выводит пути на сервере, названия таблиц, иногда куски кода прямо в браузер любого посетителя. Проверьте один раз: WP_DEBUG должен быть false в проде, а лог ошибок – писаться в файл, недоступный извне, а не на экран.
Уязвимости в коде плагинов – SQL-инъекции и XSS в отзывах
Здесь уже сложнее, потому что дело не в настройках, а в качестве чужого кода. Плагин отзывов, который вставляет текст пользователя в запрос к базе без экранирования, – классическая SQL-инъекция, через которую можно вытащить всю таблицу заказов вместе с адресами и телефонами клиентов. Плагин, который выводит комментарий «как есть», без очистки от тегов, открывает XSS: злоумышленник оставляет в отзыве не текст, а скрипт, который выполнится в браузере следующего посетителя или даже администратора, когда тот модерирует комментарии.
Полностью исключить риск, если на сайте стоят сторонние плагины, невозможно. Но вероятность можно заметно снизить: выбирать плагины с активной поддержкой и большим числом установок, смотреть на дату последнего обновления перед установкой, и поставить security-плагин с функцией virtual patching (у Wordfence она есть) – он блокирует типовые паттерны атак на уровне запроса, ещё до того, как уязвимый код в плагине успеет его обработать.
Брутфорс-атаки на вход и почему rate-limit не панацея
Даже без уязвимостей в коде сайт можно положить простым перебором – тысячи запросов к wp-login.php в минуту съедают ресурсы хостинга и рано или поздно подбирают слабый пароль. Ограничение попыток входа – это минимум, не решение. Реальная защита – спрятать wp-login.php от прямого доступа (плагины вроде WPS Hide Login позволяют задать свой URL для входа), добавить капчу на форму и вынести защиту на уровень до сервера – через firewall хостинга или Cloudflare.
REST API и XML-RPC – точки, о которых забывают
WordPress REST API по умолчанию отдаёт список пользователей сайта через /wp-json/wp/v2/users/ – включая логины администраторов, даже если отображаемое имя другое. Готовый список для брутфорса, и его часто не закрывают просто потому, что никто не проверял, как API себя ведёт.
XML-RPC – протокол ещё старше, которым почти никто не пользуется (кроме, иногда, мобильного приложения для публикации постов), но который остаётся включённым по умолчанию и активно используется для того же брутфорса, только в обход обычных лимитов на wp-login.php. Если посты не публикуются через мобильное приложение и нет интеграций, требующих XML-RPC, – отключайте его полностью через .htaccess или плагин.
HTTPS, смешанный контент и платёжные формы
SSL-сертификат сегодня есть почти у всех, про сам факт HTTPS уже мало кто забывает. А вот про смешанный контент – да: когда страница загружается по https, а картинка или скрипт подгружается по http, браузер помечает соединение как небезопасное, и часть клиентов закрывает вкладку именно на странице оплаты.
Отдельная история – платёжные формы и интеграции с эквайрингом. Если форма оплаты встроена прямо на сайт, а не редиректит на страницу банка или платёжного провайдера, сайт формально подпадает под требования PCI DSS, и хранить или даже временно логировать номера карт на своём сервере – прямой путь к штрафам и потере доверия эквайра. Правильная практика – hosted-форма оплаты или iframe от провайдера, когда данные карты вообще не проходят через ваш сервер.
Бэкапы, staging и план на случай, если всё же взломали
Даже при идеальной защите стоит исходить из того, что рано или поздно что-то пойдёт не так – новый 0-day в популярном плагине, человеческий фактор, дыра на самом хостинге. В этом случае спасает не антивирус, а бэкап, сделанный до инцидента и проверенный на восстанавливаемость.
- Автоматический бэкап базы и файлов ежедневно, с хранением вне основного сервера (UpdraftPlus с выгрузкой в облако, а не только в ту же папку на диске).
- Тестовое восстановление бэкапа раз в квартал – бэкап, который ни разу не восстанавливали, с равной вероятностью может оказаться пустым архивом.
- Обновление плагинов и темы сначала на staging-копии сайта (WP Staging или аналог у хостинга), и только после проверки – на проде. Это закрывает не только инциденты безопасности от самого обновления, но и банальные конфликты плагинов.
Если взлом уже случился – первое, что нужно сделать, это не удалять файлы в панике, а снять сайт с публичного доступа (режим обслуживания или полное отключение), сменить все пароли – от админки, базы, FTP, панели хостинга, – и уже потом разбираться, что именно попало в систему и сколько там просидело.
Ни одна из этих вещей по отдельности не занимает много времени. Проблема обычно не в сложности, а в том, что ни один пункт из списка выше так и не был закрыт с самого начала – сайт запустили, магазин начал продавать, а «сделаем безопасность потом» так и осталось на потом. Проще всего сдвинуться с места – не пытаться закрыть всё сразу, а взять один пункт на этой неделе: включить 2FA себе и менеджерам. Остальное подтянется.
Читайте также: План обновлений сайта на год: чтобы не сломать магазин в сезон; «Сайт лёг в сезон»: что должен на самом деле гарантировать SLA, чтобы бизнес не терял деньги.
