HTML面试题XSS与CSRF安全防护详解

聊到Web安全，尤其是前端领域，XSS和CSRF这两个老对手总是绕不开。很多开发者知道要防，但具体怎么防、防到什么程度，往往停留在“加个Token”或“转义一下”的模糊认知。今天，我们就来把这两类攻击的防御逻辑，特别是它们在HTML上下文中的关键点，彻底理清楚。

HTML中如何防止XSS攻击

XSS（跨站脚本攻击）的根源，其实就一句话：浏览器把本不该被执行的用户输入，当成了代码来执行。所以，防御的核心思路也异常清晰：对所有要动态插入到HTML里的内容，必须根据它所在的“上下文”，进行严格的转义或隔离。

哪些是典型的“高危操作”呢？比如，直接用 innerHTML = userInput、document.write(userInput)，用 eval() 去解析用户提供的JSON字符串，或者把URL参数不加处理就直接拼接到 href、src 这类属性里。

• 服务端渲染场景：输出数据时，必须分清目的地。是放在HTML标签体内、属性值里、Ja vaScript字符串中，还是CSS里？每个上下文都有对应的转义规则。比如PHP要用 htmlspecialchars($string, ENT_QUOTES) 来同时转义单双引号；Node.js环境下，he.escape() 这类库能帮你做上下文感知的编码。
• 前端渲染场景：首要原则是尽量避免直接操作 innerHTML。纯文本展示就用 textContent。如果用了React、Vue这类现代框架，它们默认会对插值进行转义，这提供了基础防护。但务必注意那些“危险”的API，比如React的 dangerouslySetInnerHTML 或Vue的 v-html，一旦使用，就等于把安全责任交给了开发者自己，必须人工确保内容安全。
• 富文本处理场景：这是重灾区。既然要允许用户输入HTML，就不能简单地用正则表达式去黑名单过滤，漏洞百出。行业标准做法是使用专门的净化库，比如 DOMPurify.sanitize()，它会构建一个安全的DOM树，并白名单化允许的标签和属性，从根本上禁用 、onerror、ja vascript: 等危险模式。
• 最后一道防线：部署 Content-Security-Policy (CSP) 响应头。通过策略（例如 default-src 'self'）来限制浏览器只能加载指定来源的资源，可以有效阻断大部分内联脚本执行和未经授权的外域资源加载。记住，CSP是兜底策略，不能替代前端的输出编码和输入校验。

CSRF攻击为什么HTML表单特别危险

CSRF（跨站请求伪造）的攻击逻辑和XSS完全不同。它不依赖于在受害者页面注入并执行脚本，而是利用了浏览器的一个固有行为：自动携带Cookie发送请求。传统的HTML

提交，攻击者无法被前端Ja vaScript拦截或添加自定义头部，这就导致了一个致命问题——攻击者只需要构造一个隐藏表单或一个图片链接，诱导用户点击，就能以用户的身份发起请求。

关键点在于：CSRF攻击甚至可以只用纯HTML和HTTP协议就能完成，完全不需要Ja vaScript参与。

• 核心防御：CSRF Token。所有会引起状态变更的接口（POST、PUT、DELETE等），服务端都必须生成一个随机的Token，存储在用户会话（Session）中。同时，将这个Token嵌入到表单的隐藏域（），或者放在页面的Meta标签里供前端Ja vaScript读取。服务端在处理请求时，必须校验这个Token的有效性。
• 不要过度依赖Referer/Origin头。虽然检查HTTP请求头中的Referer或Origin是常见做法，但它们可以被绕过或篡改（例如，从HTTPS页面跳转到HTTP页面时，Referer可能不会被发送）。因此，它们只能作为辅助验证手段。
• 敏感操作需二次验证。对于转账、修改密码、修改邮箱等极高风险操作，仅靠CSRF Token是不够的。必须引入二次验证，如信息验证码、邮箱确认链接等，这能从业务逻辑层面彻底杜绝CSRF。
• 利用现代浏览器的SameSite Cookie属性。为Cookie设置 SameSite=Strict 或 SameSite=Lax，可以控制浏览器在跨站请求时是否发送Cookie。这能从根本上大幅削弱由第三方站点发起的、依赖Cookie的CSRF攻击。

fetch和XMLHttpRequest能绕过CSRF防护吗

答案是：不能。只要请求携带了认证凭证（比如Cookie、Authorization头），而目标接口又没有做CSRF校验，那么无论是古老的XMLHttpRequest还是现代的fetch API，都一样会被攻击者利用。

这里细微的差别在于攻击门槛：用纯HTML表单发起CSRF攻击非常简单；而利用fetch或XHR，则需要诱导用户访问一个包含恶意Ja vaScript代码的页面（这可能涉及XSS漏洞）。但本质上，防御的焦点不在前端用什么API发送请求，而在于服务端是否对所有非幂等的请求都进行了有效的CSRF校验。

• 当使用 fetch(url, { credentials: 'include' }) 时，浏览器同样会自动附上当前站点的Cookie，其行为在携带凭证这一点上与表单提交无异。
• 有一种观点认为，如果接口只接受 Content-Type: application/json，那么传统的HTML表单（默认的 application/x-www-form-urlencoded）就无法攻击。实际上，攻击者可以通过设置
  来伪造出部分JSON结构。但这属于“深度防御”的范畴，且无法构造复杂的JSON（如带引号的键名、嵌套对象），绝不能作为主要的防护手段。
• 真正安全的做法始终如一：服务端对所有非GET/HEAD的请求，强制校验 X-CSRF-Token 请求头或请求体中的 csrf_token 参数，并与会话中存储的值进行比对。

为什么在HTML中写不算XSS

这是一个很好的理解误区澄清点。直接编写 是合法的、预期的资源加载行为，浏览器不会将其视为“用户可控的输入”进行安全判断——因为它的来源（src）是开发者硬编码或可控的白名单。

真正的风险点出现在“拼接”这个动作上。例如：。如果 userInput 是用户可控的，并且被恶意注入为 aaa";alert(1)//，就可能破坏原有的Ja vaScript语法结构，从而注入并执行任意代码。

• 黄金法则：永远不要将任何未经严格过滤的用户输入，拼接到 、、 等标签的属性值中。
• 动态加载脚本的正确姿势：如果必须动态加载，应使用 document.createElement('script') 创建元素并赋值 src，同时对这个 src 的URL进行白名单校验（例如，只允许来自特定的可信CDN域名）。
• 启用SRI（子资源完整性）：为 或 标签添加 integrity 属性，其值为该资源文件的哈希值。这样即使CDN被劫持、文件被篡改，浏览器也会因哈希校验失败而拒绝执行，这能有效防御供应链攻击。

最后，在实际项目中，有两个场景特别容易被忽略，从而成为安全短板：一是富文本编辑器的内容输出，二是URL参数回填到页面。它们看起来都只是“展示数据”，但一旦图省事，用了 innerHTML 或 document.write 来处理这些“看似安全”的数据，就等于为XSS攻击悄悄打开了一扇后门。安全无小事，细节决定成败。