SQL-инъекция чаще всего проходит там, где запросы собирают «вручную»

SQL-инъекция чаще всего проходит там, где запросы собирают «вручную»

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

Что проверять в WordPress-проекте:
— пользовательские поля в кастомных плагинах и темах;
— запросы через $wpdb->query();
— фильтры поиска, сортировки, пагинации;
— любые admin-ajax и REST-эндпоинты;
— SQL в функциях, где строки собираются через конкатенацию.

Безопасная схема одна: подготовленные запросы, параметризация и строгая валидация типов. Для чисел — приведение к int, для списков — белый список значений, для строк — prepare() вместо склейки. Экранирование само по себе не заменяет параметризацию, оно лишь снижает риск в отдельных местах 🛡️

Отдельно проверь права БД: у сайта не должно быть лишних привилегий на DROP, ALTER и доступ к чужим базам. Чем меньше возможностей у аккаунта, тем меньше ущерб, если инъекция все же найдена.

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

—
Если понравилось — посмотри @affcareers_yerevan