前端校验只是体验，不是安全

表单输入框加非空、长度、格式校验，能让用户少发一次错误请求，体验很好。但前端校验完全可以被绕过：用户直接构造请求、用脚本调用接口，前端那层校验就形同虚设。所以前端校验负责体验，真正的安全防线必须在服务端再做一遍。

本文核心知识点
  • 前端校验即时反馈，提升体验。
  • 服务端校验安全的唯一可靠防线。
  • 参数化查询从根上防 SQL 注入。
  • CSRF Token防跨站伪造请求。
表单安全校验配图：蓝色渐变背景中央表单轮廓方块叠加带对勾盾牌，左侧小对勾方块，右侧警示三角几何方块，扁平科技插画
表单叠加校验盾牌、两侧对错提示，正是表单安全与校验的意象。

服务端必须再校验一遍

任何进入服务端的数据都要当成"不可信"：类型、长度、取值范围、格式全部重新校验一遍。邮箱是不是真邮箱、年龄是不是正数、文件大小有没有超。别信任前端传过来的任何标志位，前端说"我校验过了"不算数。

防 SQL 注入：永远参数化

拼接 SQL 字符串是注入的根源。用户输入里塞一段引号加 SQL，拼进去就能偷数据甚至删表。正解是用参数化查询（预编译语句），输入永远只当数据、不当 SQL 语法。绝不在 SQL 里直接拼接用户字符串。

// 危险：拼接字符串，注入风险
db.query("SELECT * FROM user WHERE name = '" + name + "'");
// 安全：参数化，输入只当数据
db.query("SELECT * FROM user WHERE name = ?", [name]);

防 XSS：输出要转义

用户提交的内容如果原样显示在页面上，里面夹带的脚本就会被执行。把数据插到 HTML 时，要对 <、>、&、引号等做转义；用前端框架时默认自动转义，但用 innerHTML 手动塞内容时要格外小心富文本的过滤。

防 CSRF：令牌与同源校验

CSRF 是借用户已登录的身份，在别的站点偷偷代发请求。关键防护是给表单或请求加一个服务端下发、页面临时生成的 CSRF 令牌，提交时带回核对；配合 SameSite Cookie 策略与关键操作二次确认，能挡住大部分跨站伪造。校验逻辑必须在服务端做，前端校验只是体验。