SQL-инъекция — это не «взлом сайта», а дырка в каждом неэкранированном запросе

SQL-инъекция — это не «взлом сайта», а дырка в каждом неэкранированном запросе

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

Что проверять в коде:
— все запросы с переменными из $_GET, $_POST, cookies и заголовков;
— динамические ORDER BY, LIMIT, IN и LIKE;
— ручную экранизацию вместо параметризованных запросов;
— вывод ошибок БД на экран: он помогает подобрать атаку.

Для WordPress безопаснее использовать $wpdb->prepare() и строго приводить типы там, где это возможно. Но prepare не спасает, если в SQL без фильтра попадают имена таблиц, столбцов или куски выражений — такие значения нужно жёстко белым списком, а не “очищать” строкой.

Если есть старый плагин или самописный модуль, проверьте именно места, где SQL строится вручную. Один уязвимый запрос часто открывает доступ ко всей базе, поэтому лучший способ защиты — убрать склейку строк и оставить в запросах только данные, которым вы заранее доверяете.