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

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

Чаще всего уязвимость появляется там, где значение из формы, URL или cookie напрямую попадает в запрос к базе. Опасны не только поля поиска и логина: проблема есть и в фильтрах, сортировке, ID записей, AJAX-обработчиках, импорте CSV.

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

Частая ошибка — пытаться «очистить» ввод вручную через замену кавычек или черные списки символов. Это ненадежно: инъекция часто проходит через нестандартные кодировки, неожиданные поля и логику самого запроса. Безопаснее валидировать данные по белому списку и передавать их как параметры.

И еще: скрывать ошибки SQL от пользователя полезно, но не достаточно. Логи приложения должны фиксировать подозрительные запросы и падения, иначе инъекцию заметят только после выгрузки базы. Проверьте формы, AJAX и кастомные запросы в теме и плагинах — именно там защита чаще всего отсутствует.