SQL-инъекция ломает WordPress там, где запросам доверяют слишком сильно

SQL-инъекция ломает WordPress там, где запросам доверяют слишком сильно

Главная ошибка — собирать SQL из данных формы, URL или cookie вручную. Любой ввод пользователя нужно передавать через подготовленные запросы и экранирование, а не через склейку строк. Даже «безобидное» поле поиска или фильтр по категории может стать точкой входа, если там есть место для подмены.

Проверьте типовые места риска:
• кастомные плагины и темы с прямыми запросами к базе;
• AJAX-обработчики без проверки прав и nonce;
• фильтры, сортировки и поиск, где в запрос попадают параметры из GET/POST;
• импорт, экспорт и админские формы, которым доверяют по умолчанию.

Защита строится в три слоя: ограничить права БД, убрать лишние SQL-запросы из кода и валидировать каждое поле по типу. Числа приводите к int, строки — к whitelist там, где возможен выбор из фиксированного набора, а для запросов используйте $wpdb->prepare() и готовые API WordPress. Отдельно проверяйте, не выводит ли плагин ошибки SQL наружу: такие сообщения помогают атакующему.

Если в проекте есть самописный код, начните с ревизии всех мест, где в запрос попадает переменная. Один небезопасный запрос в админке часто опаснее десятка уязвимых форм на фронте.