前端安全最容易被忽视的环节往往不是XSS或CSRF本身，而是页面里那些看似无害的DOM操作、第三方脚本加载和用户输入回显。攻击者早已不满足于弹个窗证明漏洞存在，而是利用前端缺陷窃取Cookie、劫持跳转、篡改交易信息，甚至配合社会工程学完成账户接管。要提升站点安全性，必须从页面渲染、资源加载、事件绑定、数据存储四个维度逐一收紧，而不是只依赖后端防火墙。

先堵住最危险的HTML注入点

很多开发者认为只要用了前端框架就自动免疫XSS，事实并非如此。Vue的v-html、React的dangerouslySetInnerHTML、Angular的bypassSecurityTrustHtml都是明确的危险入口。一旦用户输入或接口返回的数据被塞进这些API，攻击者就能注入任意标签和事件处理器。修复方式不是简单替换成文本插值，而是要建立数据净化层。对于富文本场景，必须使用白名单过滤库，只允许特定标签和属性通过，例如只保留p、strong、a、img，并且强制为a标签添加rel="noopener noreferrer"，为img标签过滤onerror事件。对于非富文本场景，一律使用textContent或框架默认插值，禁止任何形式的HTML拼接。

另一个常被忽略的注入点是href和src属性。javascript:协议链接可以执行任意代码，data:text/html也可以加载恶意文档。所有用户可控的URL在写入href前必须校验协议头，只允许http、https、mailto、tel等安全协议。对于图片地址，还要防止SVG文件携带脚本，因为SVG内部可以嵌入script标签，当用户直接访问该图片地址时脚本会在同源环境下执行。最稳妥的做法是代理所有用户上传的图片，强制返回Content-Type为image/png或image/jpeg，并对SVG单独做沙箱处理或直接禁止上传。

脚本加载链路的完整性校验

第三方脚本是前端安全的最大不确定因素。统计代码、客服组件、广告SDK、支付插件，这些脚本运行在页面主域下，拥有读取Cookie和操作DOM的完整权限。一旦第三方服务被入侵或恶意篡改，你的站点就成了攻击者的跳板。要控制这种风险，第一原则是减少第三方脚本数量，能不用就不用，能延迟加载就延迟加载。第二原则是对所有外链脚本添加integrity属性，使用SRI（子资源完整性）校验。生成方式是对目标JS文件计算哈希值，例如：

<script src="https://cdn.example.com/sdk.js" 
        integrity="sha384-xxxxxx" 
        crossorigin="anonymous"></script>

这样浏览器会在执行前校验文件内容是否与哈希匹配，任何篡改都会导致脚本加载失败。对于无法添加SRI的动态脚本，至少要通过Content-Security-Policy限制脚本来源域名，只允许白名单内的域加载可执行代码。

用CSP把攻击面压缩到最小

Content-Security-Policy是前端防护的核心策略，但大多数站点配置得过于宽松，导致形同虚设。一个有效的CSP应该至少包含以下指令：default-src 'self'作为兜底，script-src明确列出允许的脚本源和nonce值，style-src限制样式来源，img-src限制图片加载域，connect-src限制XHR和WebSocket请求目标，frame-ancestors 'none'防止页面被嵌入iframe。对于内联脚本，不要使用'unsafe-inline'，而是通过nonce机制给每个合法内联脚本分配随机令牌。服务端生成页面时在响应头中携带nonce值，同时在script标签上标记相同nonce，攻击者注入的脚本因为没有正确nonce而无法执行。

CSP的另一个重要指令是require-trusted-types-for 'script'，这是针对DOM XSS的深度防御。开启后，所有会执行脚本的DOM API（如innerHTML、insertAdjacentHTML、document.write）都拒绝接受字符串，只接受经过Trusted Types策略处理过的对象。这能从根源上消灭大量基于字符串拼接的注入漏洞。配合report-uri或report-to指令，可以在不阻断用户的情况下先收集违规报告，逐步收紧策略。

事件监听与DOM操作的边界控制

前端代码中大量使用addEventListener绑定用户交互，但很少有人意识到事件委托的容器如果选择不当，会把攻击面扩大到整个文档树。假设你在document级别监听了click事件来处理所有按钮点击，攻击者注入一个伪造的按钮元素，点击后就会触发你的业务逻辑。正确做法是将事件绑定在最小范围的容器上，并在事件处理函数中校验event.target是否属于预期的元素类型和数据结构。对于表单提交、支付确认、权限变更等敏感操作，必须在事件处理函数内部再次校验用户状态和操作合法性，不能只依赖前端按钮的disabled属性。

DOM操作方面，使用insertAdjacentHTML、outerHTML、document.write这些API时要格外谨慎。document.write在现代浏览器中对已加载文档的调用会清空整个页面，属于高危操作，应完全禁止。对于需要动态插入节点的场景，优先使用createElement和appendChild，配合textContent设置文本内容。如果必须插入HTML片段，先通过DOMParser解析，再遍历节点树过滤危险标签和属性，最后将净化后的节点导入文档。

存储型漏洞的前端防线

localStorage和sessionStorage中保存的敏感数据是攻击者的重点目标。很多站点把用户token、个人信息甚至支付相关数据直接存在localStorage里，一旦发生XSS，攻击者一行代码就能全部读取。前端存储的正确姿势是：敏感数据一律不存localStorage，改用HttpOnly Cookie由服务端管理会话；必须存前端的非敏感数据要做加密和签名，读取时校验完整性；对于临时状态数据优先使用sessionStorage，减少持久化暴露时间。另外要定期清理过期数据，避免历史遗留的敏感信息长期驻留。

还有一个容易被忽视的存储点是IndexedDB。它容量大、异步操作，常被用来缓存接口数据。但IndexedDB的数据同样可以被同源脚本读取，且没有过期机制。如果缓存了用户订单、聊天记录、医疗信息等隐私内容，一旦被注入脚本就会批量泄露。建议对IndexedDB中存储的每条记录做字段级加密，密钥通过WebCrypto API生成并保存在内存中，页面关闭后密钥销毁，下次访问需要重新通过用户交互派生。

表单与跳转的防劫持加固

表单劫持是电商和金融类站点的重灾区。攻击者注入脚本后监听表单提交事件，在用户点击提交时把数据先发送到恶意服务器，再放行正常提交。这种攻击隐蔽性极高，用户完全无感知。防护手段包括：对表单提交事件做防重入处理，在提交前校验表单action属性是否被篡改，使用requestAnimationFrame或微任务机制检测提交瞬间的DOM变化。更有效的方式是放弃传统表单提交，改用fetch或XMLHttpRequest发送数据，并在请求头中加入自定义签名，服务端验证签名不匹配则拒绝请求。

跳转劫持同样危险。前端代码中经常使用location.href、window.open、location.replace进行页面跳转，如果跳转地址来自URL参数或用户输入，攻击者可以构造恶意链接诱导用户点击后跳转到钓鱼页面。所有跳转操作必须经过白名单校验，只允许跳转到站内路径或已备案的合作域名。对于从URL参数中获取的redirect参数，要解析出目标域名并与白名单比对，不匹配则强制跳转到首页。window.open打开的新窗口还要设置opener为null，防止新页面通过window.opener操作原页面。

前端日志与异常监控的安全价值

安全防护不能只靠事前拦截，事中检测和事后追溯同样重要。前端应该部署轻量级的异常监控脚本，捕获全局错误、未处理的Promise拒绝、资源加载失败、接口异常等事件。这些日志中往往包含攻击痕迹，例如突然出现大量脚本加载失败可能意味着CSP拦截了注入脚本，某个接口的异常参数可能暴露了攻击者在尝试注入。监控脚本本身要放在独立域名下，避免与业务代码共享Cookie，同时日志上报接口要做签名和频率限制，防止攻击者利用监控通道进行数据外传。

对于安全敏感事件，例如登录、支付、权限变更、敏感数据查看，前端应该主动上报审计日志。日志内容包含事件类型、时间戳、用户标识、操作对象、来源页面，但不包含密码、token等敏感字段。这些日志配合服务端的访问日志，可以快速定位安全事件的影响范围和攻击路径。前端日志的存储使用sendBeacon或fetch的keepalive选项，确保页面关闭时也能发送成功。

把安全校验嵌入构建流程

前端安全不能只靠开发者自觉，必须通过工具链强制约束。在CI/CD流程中加入安全扫描步骤，对每次构建产物进行静态分析。扫描规则包括：检测代码中是否出现dangerouslySetInnerHTML、v-html、eval、new Function等危险API；检查所有外部脚本是否配置了integrity属性；验证CSP头是否在测试环境正确下发；扫描依赖包中是否存在已知漏洞。对于扫描出的高危问题直接阻断发布，中低危问题生成报告通知开发者限期修复。

依赖安全同样关键。前端项目动辄引入几百个npm包，其中任何一个被植入恶意代码都会直接进入构建产物。使用npm audit或专业供应链安全工具定期扫描依赖树，锁定关键依赖的版本，避免使用来源不明的fork包。对于需要加载远程脚本的场景，建立内部代理机制，将第三方脚本下载到自有服务器后经过安全审查再提供给页面引用，这样既能控制脚本内容变化，又能避免第三方服务故障影响站点可用性。

前端页面漏洞防护是一个持续收紧的过程，没有一劳永逸的方案。攻击手法在不断演进，防护策略也要跟着迭代。从最基础的输入输出过滤，到CSP和SRI的深度应用，再到构建流程的安全卡点，每一层都在增加攻击者的成本。真正安全的站点不是没有漏洞，而是让漏洞利用的代价高到攻击者放弃。