SQL注入必然可被利用，因前端校验可被curl/Burp绕过；必须后端用参数化查询（如?占位符）、禁用字符串拼接、白名单校验动态标识符，并配最小权限数据库账号。
React + Node 全栈项目里，SQL 注入根本防不住——只要后端存在字符串拼接 SQL 的逻辑，前端再怎么校验、加密、拦截都毫无意义。防御必须落在 Node 层的查询构造环节，且必须全程隔离用户输入与 SQL 结构。
Node 层必须用参数化查询，不能只靠 ORM 就松懈
Sequelize、Prisma、TypeORM 等 ORM 默认启用参数化，但它们也留了后门：原生 SQL 接口（如 sequelize.query()、prisma.$queryRaw）一旦拼接用户输入，立刻失效。
-
sequelize.query('SELECT * FROM users WHERE name = ?', [req.body.name])✅ 安全 -
sequelize.query(`SELECT * FROM users WHERE name = '${req.body.name}'`)❌ 危险，哪怕用了escape也不可靠（escape仅适配 MySQL，且对嵌套上下文、多字节编码等场景有绕过风险） -
prisma.$queryRaw`SELECT * FROM users WHERE id = ${req.body.id}`❌ 模板字符串插值不是参数化，是拼接
ORM 不是银弹，关键看你怎么用。检查项目中所有 query、$queryRaw、raw() 调用点，确认参数是否通过数组或命名对象传入，而非字符串插值。
动态表名/字段名必须走白名单，不能“过滤后拼接”
参数化查询只支持值（WHERE 条件、INSERT 值），不支持结构（表名、列名、ORDER BY 字段、GROUP BY 字段）。这类动态部分一旦拼接，就等于开了后门。
- ❌
const sql = `SELECT * FROM ${req.query.table} WHERE id = ?` - ✅ 把允许的表名硬编码为对象键：
const allowedTables = { users: 'users', posts: 'posts' }; const table = allowedTables[req.query.table] || 'users'; - ✅ 排序字段同理：
const sortFields = { name: 'name', createdAt: 'created_at' }; const field = sortFields[req.query.sort] || 'id'; const sql = `SELECT * FROM users ORDER BY ${field} ${req.query.order === 'desc' ? 'DESC' : 'ASC'}`
别信“我用正则过滤了单引号和分号”，攻击者可以用反引号、十六进制编码、宽字节绕过。白名单是唯一可验证、可审计、无例外的方案。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
React 层的任何处理对 SQL 注入零防护力
你在 React 里加 v-model 校验、onSubmit 阻止、zod schema 验证、甚至前端 MD5 加密密码——这些全被 curl 或 Burp Suite 一发原始请求绕过。
- ❌
if (!/^[a-z0-9_]+$/.test(username)) return alert('非法字符')—— 攻击者直接 POST{"username": "admin'--"} - ❌ 前端把密码转成
md5('123456')再发 —— 后端收到的仍是可控字符串，照样能拼进 SQL - ✅ React 唯一该做的事：给用户清晰反馈、防止误操作、配合后端做输入提示（比如邮箱格式），仅此而已
把安全责任推给前端，等于在银行金库门口贴张“请勿盗窃”的纸条。
数据库账号权限必须最小化，别用 root 连接
即使某处漏掉参数化，最小权限也能卡住攻击者的横向移动。一个只查 users 表的接口，数据库账号就不该有 DROP TABLE、UNION SELECT、读取 information_schema 的权限。
- MySQL 示例：
CREATE USER 'app_readonly'@'%' IDENTIFIED BY 'strong_pwd'; GRANT SELECT ON mydb.users TO 'app_readonly'@'%'; FLUSH PRIVILEGES; - PostgreSQL 示例：
CREATE ROLE app_user NOSUPERUSER NOCREATEDB NOCREATEROLE; GRANT SELECT ON TABLE users TO app_user;
权限收紧后，即便注入成功，攻击者最多看到几行数据，拿不到表结构、无法写文件、不能执行系统命令——这道防线常被忽略，却是最后也是最实在的一道闸。
真正难的不是写对一行 execute(sql, [val])，而是确保整个代码库没有一处 + 或模板字符串把 req.body.xxx 塞进了 SQL 字符串。每次加新查询，都要问一句：这个变量，是不是可能来自用户？它出现在 SQL 的哪个位置？能不能被参数化？不能的话，白名单够不够死？数据库账号有没有被过度授权？
