Коротко: основной риск — SQL‑инъекция. Ниже перечислены векторы атак, реальные полезные исправления в коде, настройки СУБД и архитектурные меры.

Векторы атак (с примерами полезных нагрузок)

Вставка логического выражения / обход фильтрации: например (1\ \text{OR}\ 1=1) — вернёт все записи. UNION‑инъекция: например ('1' UNION SELECT user, password FROM users --). Time‑based blind: ('1' OR IF(condition, SLEEP((5)), 0) --) — замер времени даёт утечку. Stacked queries (если разрешены): ('1'; DROP TABLE users; --). Error‑based: вызов функций/операторов, приводящих к ошибкам и раскрывающих данные. Out‑of‑band (DNS/HTTP exfiltration) при наличии функций UDF/LOAD_FILE/внешних запросов. Second‑order: вредоносные данные сохраняются и используются позже в уязвимом запросе. Обход фильтров через кодировки/комментарии/вложенные запросы.

Конкретные исправления на уровне кода (PHP)
1) Использовать подготовленные выражения всегда (пример PDO):

$pdo = new PDO($dsn, $user, $pass, [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false, // отключить эмуляцию
]);
// если id — целое:
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id===false)/\ast 400BadRequest\ast /$stmt = $pdo->prepare('SELECT * FROM items WHERE id = :id');
$stmt->execute(['id' => $id]);$row = $stmt->fetch();

2) Если используете mysqli:

$mysqli = new mysqli($host,$user, $pass,$db);
$stmt=$mysqli->prepare('SELECT * FROM items WHERE id = ?');
$intId=(int)$_GET['id'];
$stmt->bind_param('i', $intId);
$stmt->execute();
$res=$stmt->get_result();

3) Валидация и приведение типов: если id — число, обязательно проверять через filter_var(..., FILTER_VALIDATE_INT) или (int) + проверку диапазона. Дополнительно использовать allowlist для строковых значений.
4) Никогда не строить запросы через конкатенацию с пользовательскими данными; если вынужденно — тщательно экранировать при помощи mysqli_real_escape_string() (как крайняя мера).
5) Отключать вывод подробных ошибок БД пользователю; логировать внутрь защищённого журнала.

Исправления конфигурации СУБД

Создать отдельного пользователя БД с минимумом привилегий (только SELECT/INSERT/UPDATE/DELETE, только на нужные таблицы). Отключить возможность выполнения нескольких выражений в одном запросе (не использовать multi_query; для PDO можно выставить PDO::MYSQL_ATTR_MULTI_STATEMENTS в false если доступно; явно не разрешать мульти‑запросы). Ограничить доступ к БД по сети (bind‑address, firewall), запретить удалённый root. Установить корректную кодировку соединения (utf8mb4) и использовать её при экранировании. Включить аудит/логирование подозрительных запросов; настроить alerting на аномалии (частые медленные запросы, SLEEP и т.п.). Ограничить возможности UDF и функции загрузки файлов (LOAD_FILE) если не нужны.

Архитектурные меры

Централизованный слой доступа к данным (DAL/Repository), где все запросы проходят через единый интерфейс с обязательной параметризацией. Использование ORM/Query Builder с поддержкой параметров (Doctrine, Eloquent и т.п.). Внедрить WAF (например ModSecurity) с правилами против SQL‑инъекций как дополнительный барьер. Принцип наименьших привилегий везде (БД, приложение, ОС). Регулярный SAST/DAST и пентесты, включая автоматические тесты на SQL‑инъекции; CI‑контроль правил кодирования. Логи и мониторинг задержек/аномалий (time‑based атаки), защита от брутфорса и rate limiting. Не хранить чувствительные данные в виде, доступном через уязвимые запросы; использовать шифрование/токены.

Краткие рекомендации при исправлении существующего кода

Замените все конкатенации запросов на подготовленные выражения. Для числовых идентификаторов: валидируйте и приводите к типу. Проведите ревизию БД‑пользователей и прав доступа. Запустите сканер на SQL‑инъекции и выполните ручное тестирование (в т.ч. blind/time/union). Добавьте автоматические unit/integration тесты, которые проверяют, что опасные полезные нагрузки не проходят.

Если нужно, могу:

Привести правку конкретного вашего фрагмента кода. Сформулировать checklist для аудита.