Controller层类型转换不能防止SQL注入，真正有效的是数据库操作层的参数化查询，它将SQL结构与用户输入彻底分离，确保恶意输入如' OR 1=1--仅被当作字符串值处理。

Controller 层做类型转换不能防止 SQL 注入，这是常见误解。SQL 注入发生在数据库查询拼接环节，和参数是字符串还是数字无关——只要用字符串拼接 SQL，就可能被绕过。

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

---

Controller 层强制转 parseInt 或 Number() 只防得住整数型参数，但拦不住 ' OR 1=1 -- 这类字符串注入

• 常见错误写法：

  const id = parseInt(req.query.id); // ✅ 转成数字
  const sql = `SELECT * FROM users WHERE id = ${id}`; // ❌ 仍属拼接，且 id 为 NaN 时变成 `WHERE id = NaN`

• 问题在于：类型转换只是预处理，没解决根本问题——SQL 字符串仍由用户输入参与构造
• 更危险的是，开发者误以为“转了类型就安全”，反而放松对其他字段（如 username、email）的防护

---

真正起作用的是在数据库操作层使用参数化查询，不是 Controller 层

• 正确路径：
  Controller → 校验/清洗（可选）→ 传给 Service → Service 调用带参数绑定的查询（如 pool.execute、query 的占位符模式）
• 示例（MySQL2 + Promise Pool）：

  // ✅ 安全：参数与 SQL 结构分离
  const [rows] = await pool.execute(
    'SELECT * FROM users WHERE username = ? AND status = ?',
    [req.body.username, 'active']
  );

• 即使 username 是 'admin' OR '1'='1'，也会被当做一个完整字符串值处理，不会改变 SQL 逻辑

---

Controller 层该做什么？校验边界，不越权处理数据形态

• 对 ID 类参数，可用 parseInt + isNaN 拦截明显非法值，但仅作快速失败（fail-fast），不是安全屏障
• 对字符串字段，应限制长度、过滤控制字符（如 \x00、\r\n），但绝不依赖正则“黑名单”防注入
• 所有数据库交互必须交由专用 DAO / Service 方法，且这些方法内部禁止拼接 SQL 字符串
• 若用 ORM（如 Prisma、Sequelize），确保启用原生参数绑定（避免 raw()、query() 直接拼接）

---

真正容易被忽略的一点：前端传来的任何数据——包括 req.headers、req.cookies、req.query、req.body，甚至 req.ip——只要进到 SQL 查询里，就必须走参数绑定。类型转换只是辅助手段，不是防御动作。