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，对现代攻击基本无效。真正的防线在服务端。

  • 所有 API 请求必须携带有效认证凭证（如 Authorization hea

    

    der），且后端每次验证签名与时效性
  • 修改类接口（如 PATCH /api/orders/123）必须校验当前用户是否有权操作 ID=123 的资源，不能只查登录态
  • 避免使用全局可预测的 ID（如自增数字），改用 UUID 或服务端签发的短链 token，降低遍历风险

  最常被忽略的一点：前端安全不是“写完再加固”，而是从第一个 fetch 调用开始，就默认后端没校验、用户已篡改、网络被监听。所有防御措施，最终都要回归到“这个值，后端是否重新确认过？”