SQL-инъекция — это не «взлом БД», а ошибка в том, как сайт принимает ввод

SQL-инъекция — это не «взлом БД», а ошибка в том, как сайт принимает ввод

Главный риск возникает там, где запрос собирают из текста пользователя: логины, поиск, фильтры, параметры URL, формы обратной связи. Если значение попадает в SQL без строгой обработки, атакующий может изменить смысл запроса и получить чужие данные, обойти авторизацию или повредить таблицы.

В WordPress уязвимые места чаще всего появляются не в ядре, а в плагинах и кастомных темах. Особенно опасны:
— прямой конкатенированный SQL;
— ручная вставка $_GET и $_POST в запрос;
— самописные панели и фильтры без подготовки данных;
— запросы к wpdb без prepare().

Защита строится на простых правилах: используйте prepared statements, типизируйте входные данные, ограничивайте права SQL-аккаунта и не доверяйте строкам из запроса даже после sanitization. Sanitization убирает мусор, но не заменяет параметризацию. Если нужен поиск по тексту или сортировка, разрешайте только белый список значений.

Полезная привычка: просматривайте код плагинов на места, где есть SELECT, INSERT, UPDATE или DELETE рядом с переменными. Если видите склейку строки и данных пользователя — это повод остановиться и переписать участок. Чем раньше найден такой шаблон, тем меньше шанс, что уязвимость уйдёт в продакшн.