SQL-инъекция — это не баг базы, а ошибка в обработке пользовательского ввода

SQL-инъекция — это не баг базы, а ошибка в обработке пользовательского ввода

Чаще всего уязвимость появляется там, где запрос собирают строкой: из GET/POST, cookie, заголовков, полей профиля, поиска. Атакующему не нужен доступ к админке — достаточно найти место, где символы из ввода попадают в SQL без параметризации.

Что должно насторожить:
• конкатенация запросов через . или +
• ручная экранизация вместо prepared statements
• фильтрация «через blacklist» вместо whitelist
• скрытые поля и параметры, которым доверяют как внутренним

Защита начинается с трёх правил: используйте параметризованные запросы, ограничивайте права учетной записи БД и проверяйте типы данных до обращения к SQL. Текстовый ввод — только как данные, никогда как часть команды. Для поиска, сортировки и фильтрации лучше заранее задавать разрешённые значения, а не пропускать произвольную строку.

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

Лучший тест простой: если пользовательский ввод можно вставить в запрос и он меняет структуру SQL, у вас уже проблема.