前端过滤对sql注入完全无效，因ui层控制（如disabled、maxlength）可被devtools或curl绕过；真正防护必须依赖后端参数化查询、动态结构白名单校验及最小权限数据库账号。
前端过滤对 SQL 注入完全无效，它既不能改变数据库解析行为，也无法阻止攻击者绕过。真正起作用的只有服务端的参数化查询、白名单校验和最小权限数据库账号。
为什么删掉 disabled 或改 maxlength 就能绕过前端限制
浏览器的 disabled、readonly、maxlength 属性只是 UI 层控制，不参与服务端逻辑。攻击者打开 DevTools 删除属性，或直接用 curl/Postman 发请求，就能提交任意内容。
-
document.getElementById('user').value = "admin' OR 1=1 --"这种 JS 拼接照样能发出去 - React/Vue 的双向绑定 + 正则校验，HTTP 请求本身完全不受控
- 前端校验只用于提升体验，不是安全边界
mysql2.query("SELECT * FROM u WHERE n = '" + x + "'") 是高危写法
这种字符串拼接会把用户输入直接嵌入 SQL 文本，数据库解析器无法区分哪部分是代码、哪部分是数据。一旦输入含 ' OR 1=1 --，整条语句逻辑就被篡改。
- 正确做法：用占位符，如
db.query("SELECT * FROM users WHERE name = ?", [req.body.name]) - PostgreSQL 同理：
client.query("SELECT * FROM logs WHERE level = $1", ["error"]) - MyBatis 中必须用
#{}，禁用${}（后者等价于字符串拼接）
ORM 也不绝对安全：原始 SQL 和动态结构是重灾区
Sequelize、TypeORM、SQLAlchemy 等框架默认生成参数化查询，但一旦调用 .raw()、.query() 或拼接表名/字段名，就退回高危模式。
- 危险：
User.sequelize.query(`SELECT * FROM ${tableName}`)—— 表名不能参数化，必须白名单校验 - 危险：
db.session.execute(f"UPDATE logs SET status = '{status}'")——f-string拼接 = 直接裸奔 - 安全：
User.query.filter(User.name == name).all()或db.session.execute(text(" :s"), {"s": status})
最容易被忽略的是“动态结构”的处理——比如多租户系统里根据子域名切换 schema，或报表模块允许选不同表查询。这类场景下，table_name、order_by、limit 等都不能靠参数化，必须用严格白名单 + 正则校验 + 最小权限 DB 账号兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
