> Как защититься от SQL инъекции (JavaScript)

Короткий ответ

SQL-инъекции предотвращаются использованием параметризованных запросов (prepared statements) вместо конкатенации строк. В Node.js это достигается через библиотеки вроде pg с placeholders ($1, $2), в Java - через PreparedStatement. Дополнительно применяется валидация и экранирование входных данных, а также ORM с безопасными query builder'ами. Никогда не доверяйте пользовательскому вводу.

Подробное объяснение

SQL-инъекция возникает, когда злоумышленник вставляет вредоносный SQL-код через входные данные (например, поля форм, URL-параметры). Если приложение конкатенирует строки напрямую, злоумышленник может изменить структуру запроса: SELECT * FROM users WHERE name = 'admin' OR '1'='1'.

Основные методы защиты:

1. Параметризованные запросы (prepared statements) - самый надёжный способ. SQL-шаблон компилируется заранее, а параметры передаются отдельно, что исключает интерпретацию ввода как кода. Это работает на уровне драйвера БД.

2. Экранирование входных данных - менее предпочтительно, так как легко ошибиться. Используется как дополнительная мера.

3. Валидация и санитизация - проверка типа данных (число, UUID, enum), длины, регулярные выражения. Например, для id используйте Number(id) или parseInt.

4. ORM и query builder'ы (Sequelize, TypeORM, Prisma, Hibernate) - они по умолчанию используют параметризацию, но не защищают от ошибок в raw-запросах.

5. Принцип наименьших привилегий - у пользователя БД должны быть минимальные права (только SELECT, без DROP).

На практике

Для frontend-разработчика, работающего с Node.js и Java, защита от SQL-инъекций обычно реализуется на бэкенде. Однако важно понимать, что:

• В Node.js с pg используйте client.query('SELECT * FROM users WHERE id = $1', [userId]).
• В Java с JDBC - PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?"); ps.setInt(1, userId);.
• Избегайте raw-запросов в ORM (например, sequelize.query('SELECT ...') без параметров).
• Для динамических условий (IN, ORDER BY) используйте белые списки допустимых значений, а не подстановку строк.
• Валидируйте входные данные на клиенте, но не полагайтесь на это - всегда проверяйте на сервере.

Пример кода

Node.js с библиотекой pg (правильно):

JAVASCRIPT
const result = await pool.query(
  'SELECT * FROM users WHERE email = $1 AND active = $2',
  [userInput.email, true]
);

Node.js с pg (опасно):

JAVASCRIPT
const result = await pool.query(
  `SELECT * FROM users WHERE email = '${userInput.email}' AND active = true`
);

Java с JDBC (правильно):

JAVA
String sql = "SELECT * FROM users WHERE email = ? AND active = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, userInput.getEmail());
ps.setBoolean(2, true);
ResultSet rs = ps.executeQuery();

Как отвечать на собеседовании

Начните с чёткого определения проблемы: SQL-инъекция - это внедрение вредоносного SQL-кода через пользовательский ввод. Затем сразу переходите к главному решению - параметризованным запросам. Упомяните, что это работает на уровне драйвера БД, а не на уровне приложения. Приведите пример на Node.js и Java. Добавьте про ORM и валидацию как дополнительный слой. Если спросят про динамические запросы (например, сортировка по столбцу), объясните про белые списки. Не углубляйтесь в экранирование - это legacy-подход.

Что проверяет интервьюер

• Понимание механизма инъекции (как именно злоумышленник может изменить запрос).
• Знание практических инструментов защиты (prepared statements, ORM).
• Умение различать безопасные и опасные паттерны в коде.
• Понимание, что защита должна быть на сервере, а не на клиенте.
• Осведомлённость о дополнительных мерах (валидация, привилегии).

Типичные ошибки

• Предложение экранирования как основного метода защиты (это ненадёжно).
• Уверенность, что ORM полностью защищает от инъекций (если использовать raw-запросы - нет).
• Игнорирование динамических запросов (например, сортировка через конкатенацию).
• Фокус только на клиентской валидации.
• Путаница между SQL-инъекцией и XSS (разные векторы атак).