SQL-инъекция проходит там, где ввод пользователя попадает в запрос без строгой проверки

SQL-инъекция проходит там, где ввод пользователя попадает в запрос без строгой проверки

Чаще всего уязвимость появляется в формах поиска, фильтрах, логине, комментариях и параметрах URL. Опасен не сам SQL, а момент, когда строка из поля ввода склеивается с запросом напрямую: злоумышленник подставляет свои фрагменты и меняет логику выборки.

Что снижает риск:
— параметризованные запросы и подготовленные выражения;
— запрет ручной сборки SQL через конкатенацию;
— whitelist для сортировки, фильтров и имен полей;
— отдельные права у пользователя БД: не давать лишнее, если сайт только читает данные;
— экранирование не спасает само по себе, если архитектура уже неверная.

На WordPress уязвимость часто рождается не в ядре, а в теме, плагине или самописном коде. Особенно опасны места, где разработчик доверяет `$_GET`, `$_POST` и значениям из AJAX без `prepare`, `sanitize` и проверки типа. Даже админка не делает запрос безопасным, если в коде нет разделения между данными и командой.

Проверьте самые подозрительные точки: поиск, сортировку, фильтры, экспорт, кастомные REST-эндпоинты и SQL в хуках. Если запрос можно собрать строкой, его нужно переписать так, чтобы данные передавались отдельно от структуры запроса.