JavaScript无法保证安全性，所有前端代码均可被篡改；关键逻辑必须后端校验，前端仅展示与提交；敏感数据不可信，需服务端鉴权与验证。
JavaScript 本身无法“保证”安全性，它运行在不可信环境（如浏览器），所有前端代码都可被用户查看、修改、绕过。所谓“防御”，本质是增加攻击成本、防止误操作、配合后端做纵深校验，而不是靠前端锁死逻辑。
不要信任任何 document、localStorage 或 URL 参数
用户能随时改 localStorage.token、伪造 location.search、篡改 DOM 中的隐藏字段。前端存储的敏感信息（如权限标识、价格、状态）必须视为无效数据。
- 把权限判断、金额计算、状态流转等关键逻辑全部移到后端，前端只负责展示和提交
- URL 中的
id、type等参数，前端用前应先校验格式（如/^\d+$/），但绝不据此决定是否渲染按钮——按钮显隐仍需后端返回的canEdit: true字段 -
localStorage只存非敏感缓存（如主题偏好），且每次读取后应做类型/范围校验，避免注入恶意 JSON 或原型污染值
防范 XSS：永远不直接用 innerHTML 插入用户输入
只要把用户可控内容拼进 HTML，就可能触发脚本执行。哪怕加了 escape，也容易漏掉事件属性、CSS 表达式等绕过方式。
- 优先用
textContent渲染纯文本；需要富文本时，用成熟库（如DOMPurify.sanitize()）过滤，而非正则替换 - 动态生成链接时，不要写
el.innerHTML = '...'，改用el.setAttribute('href', url)并确保url以https://或/开头（防javascript:伪协议） - 模板字符串中避免插值到事件属性：
`` 是高危写法，必须禁止避免 CSRF 和越权调用：每个请求都依赖后端鉴权与校验
前端加
X-Requested-With、拦截 403 响应、或本地存 CSRF token，对现代攻击基本无效。真正的防线在服务端。立即学习“Java免费学习笔记（深入）”；
- 所有 API 请求必须携带有效认证凭证（如
Authorizationheader），且后端每次验证签名与时效性 - 修改类接口（如
PATCH /api/orders/123）必须校验当前用户是否有权操作 ID=123 的资源，不能只查登录态 - 避免使用全局可预测的 ID（如自增数字），改用 UUID 或服务端签发的短链 token，降低遍历风险
最常被忽略的一点：前端安全不是“写完再加固”，而是从第一个
fetch调用开始，就默认后端没校验、用户已篡改、网络被监听。所有防御措施，最终都要回归到“这个值，后端是否重新确认过？” - 所有 API 请求必须携带有效认证凭证（如
