SQL-инъекция ломает не только форму входа: уязвимым бывает любой запрос к БД

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

Что делать:
• использовать подготовленные запросы и параметризованные выражения;
• не собирать SQL через конкатенацию;
• жёстко проверять типы и список допустимых значений;
• выдавать пользователю только общую ошибку, а детали писать в лог.

Отдельно проверь места, где разработчик «доверяет» внутренним параметрам: id, role, status, order_by. Если значение попадает в SQL без белого списка, защита уже условная. Особенно это важно в самописных плагинах, AJAX-обработчиках и старых шаблонах.

Если нужен быстрый аудит, ищите в коде слова SELECT, INSERT, UPDATE и точки, где рядом стоят данные из $_GET, $_POST, $_COOKIE или переменных из API. Один такой участок часто открывает доступ ко всей базе.