SQL-инъекция ломает сайт там, где запросы собираются из чужого ввода

SQL-инъекция ломает сайт там, где запросы собираются из чужого ввода

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

Что проверять в коде:
• все запросы к БД должны идти через подготовленные выражения;
• входные данные — через sanitization и validation, а не «на глаз»;
• права пользователя БД — только минимально нужные;
• сообщения об ошибках не должны показывать текст SQL на экран.

Отдельно опасны места, где разработчик «усложнил» фильтр: экранирование символов без параметризации, ручная сборка IN()-списков, запросы в AJAX-обработчиках и REST-эндпоинтах. Если защита держится на одном if или регулярке, её обычно обходят через альтернативный формат ввода.

Проверьте все точки, где сайт принимает данные и сразу обращается к базе: форма, поиск, фильтр, API, админка, импорт. Если запрос нельзя прочитать как шаблон с параметрами, его уже пора переписывать.