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

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

SQL-инъекция возникает там, где данные пользователя склеивают со строкой запроса. Поле логина, поиск, фильтр, сортировка, параметр в URL — всё это может стать точкой входа, если значение вставляют без подготовки. В WordPress особенно уязвимы плагины и самописные обработчики, где разработчик экономит время и пишет прямой запрос.

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

Для защиты важно смотреть не только на код, но и на поведение: неожиданные ошибки БД, странные 500-ответы, лишние запросы к базе, всплеск нагрузки на поиск. Если админка или фронт начинают “сыпаться” после обычных вводов, это повод проверить места, где SQL собирается вручную.

Самый надёжный подход — убрать ручную сборку запросов, провести ревизию плагинов и отдельно проверить все формы, где данные попадают в базу или влияют на выборку.