前端安全与JavaScript XSS防护策略

XSS（跨站脚本攻击）是前端最常见的安全漏洞之一，其防护需贯穿开发全流程，核心原则是“不信任用户输入，严格处理输出”。 以下是基于JavaScript的XSS防护策略，结合攻击类型、输入验证、输出编码、危险API规避及安全策略配置，构建多层防御体系：

XSS分为三类，攻击方式不同但目标一致：在用户浏览器中执行恶意脚本。

• 反射型XSS：恶意脚本通过URL参数传入（如?query=<script>...</script>），服务器拼接后立即执行，常用于钓鱼链接。
• 存储型XSS：攻击者将恶意代码提交至服务器（如评论、用户资料），其他用户访问时从数据库加载并执行，危害范围广。
• DOM型XSS：不经过后端，完全由前端JavaScript动态操作DOM引发（如通过location.hash或innerHTML注入），隐蔽性强。

基础原则：区分“数据”与“代码”，用户输入视为纯文本，禁止直接执行。

• 白名单过滤：对输入进行严格校验，仅允许特定字符或格式（如邮箱、手机号），拒绝所有非预期内容。
• 上下文编码：根据输出位置选择编码方式：

  HTML内容：使用HTML实体编码（如<转为&lt;，>转为&gt;），防止标签解析。

  JS字符串：对嵌入数据做JavaScript编码（如"转为x22，'转为x27），避免字符串逃逸。

  URL参数：使用encodeURIComponent处理，确保特殊字符（如?、&）不被解析为URL分隔符。

某些API易引发XSS，需谨慎使用或替代：

• 禁用innerHTML：改用textContent插入用户数据，防止HTML标签解析。// 危险示例element.innerHTML = userInput; // 可能执行恶意脚本// 安全替代element.textContent = userInput; // 仅作为文本显示
• 禁用动态执行：避免eval()、new Function()、setTimeout(string)等动态执行字符串的方法。
• 谨慎操作URL与DOM：

  不要直接使用location.href或document.write接收不可信数据。

  避免通过location.hash、search等动态加载内容时未编码。

• 富文本处理：使用DOMPurify等库清理富文本，仅保留安全的HTML标签（如<b>、<i>），移除<script>、on*事件等危险属性。import DOMPurify from 'dompurify';const cleanHtml = DOMPurify.sanitize(userInput);

通过浏览器机制构建多层防御：

• Content-Security-Policy (CSP)：

  限制脚本来源：script-src 'self'

  https://trusted.cdn.com
  ，禁止内联脚本（unsafe-inline）和eval()。

  禁止内联样式：style-src 'self'，防止通过style属性注入。

  示例配置：Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'

  https://api.example.com;

• HttpOnly Cookie：设置HttpOnly标志，防止通过document.cookie窃取会话令牌。Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
• X-XSS-Protection：虽现代浏览器逐步弃用，但仍可作为补充（如X-XSS-Protection: 1; mode=block）。

• 输入阶段：前端校验+后端验证，双重保障数据合法性。
• 输出阶段：根据上下文动态选择编码方式，避免“一刀切”。
• 部署阶段：配置CSP、HttpOnly等安全头，定期审计依赖库（如DOMPurify版本）。
• 测试阶段：使用工具（如OWASP ZAP、Burp Suite）扫描XSS漏洞，模拟攻击测试防御效果。

• 过度依赖单一防护：如仅用CSP而忽略输入编码，或仅过滤输入而未处理输出。
• 忽略DOM型XSS：认为后端过滤即可，但前端动态操作DOM仍可能引发漏洞。
• 富文本处理不当：直接使用innerHTML显示用户提交的HTML，未清理危险标签。

总结：XSS防护需结合输入验证、输出编码、危险API规避及安全策略配置，形成“输入过滤-输出编码-环境隔离”的多层防御。开发者应始终假设用户输入不可信，并在每个环节严格处理，避免因细节疏忽导致安全漏洞。