SQL-инъекция ломает WordPress не через код, а через доверие к чужому вводу

SQL-инъекция ломает WordPress не через код, а через доверие к чужому вводу

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

Где чаще всего ошибаются:
— берут $_GET, $_POST или $_COOKIE и вставляют в запрос напрямую;
— путают экранирование с валидацией;
— доверяют полям из админки, REST API и AJAX-обработчиков;
— используют небезопасные кастомные SQL вместо готовых методов WordPress.

Защита строится на трех правилах: использовать $wpdb->prepare() для всех динамических значений, ограничивать тип и формат входных данных до запроса, а для простых операций — выбирать встроенные функции WordPress, а не собирать SQL вручную. Если параметр должен быть числом, приводите его к int; если это строка, проверяйте длину и допустимые символы.

Полезная привычка: просматривайте код глазами атакующего и ищите места, где пользователь может повлиять на WHERE, ORDER BY или LIMIT. Именно там SQL-инъекции появляются чаще всего.