防御XSS与CSRF需多层防护：对XSS，应严格编码输出、实施CSP策略；对CSRF，应使用CSRF Token、SameSite Cookie等机制，并结合HttpOnly、HTTPS等安全实践。
前端安全的核心挑战之一，无疑是XSS（跨站脚本攻击）和CSRF（跨站请求伪造）这两种经典攻击。要有效防御它们，关键在于从输入、输出、会话管理以及请求验证等多个层面构建一套严密且多层次的防护体系，没有一劳永逸的银弹，更多是组合拳的运用。
解决方案
面对XSS与CSRF，我们不能仅仅依赖单一的技术手段。我的经验是，防御需要从前端到后端，从开发到部署，全方位地渗透。对于XSS，核心在于“不信任任何用户输入，对所有输出到页面的内容进行严格编码”，并辅以内容安全策略（CSP）。而CSRF，则着重于“验证请求的来源与合法性”，常用的如CSRF Token、SameSite Cookies等。这不仅仅是技术实现，更是一种安全意识的养成。
深入剖析XSS攻击的种类与核心防御机制
XSS攻击，简而言之，就是攻击者设法在你的网站上注入恶意脚本，当其他用户访问时，这些脚本就会在他们的浏览器中执行。我个人觉得，理解它的种类有助于我们更精准地防御。
常见的XSS大致分三类：
立即学习“前端免费学习笔记（深入）”；
- 存储型XSS (Stored XSS)：这是最危险的一种。恶意脚本被永久地存储在服务器上（比如数据库、评论区、论坛帖子），当用户访问包含这些脚本的页面时，脚本就会被执行。想象一下，你在一个社交网站上发了个带恶意代码的帖子，所有看到这个帖子的人都可能中招。
- 反射型XSS (Reflected XSS)：这种攻击通常通过URL参数注入。攻击者构造一个包含恶意脚本的URL，诱骗用户点击。服务器接收到请求后，没有对恶意脚本进行处理就直接“反射”回浏览器，导致脚本执行。比如一个搜索框，你输入 ，如果直接显示出来，就可能存在反射型XSS。
- DOM型XSS (DOM-based XSS)：这种XSS的特殊之处在于，它不涉及服务器端，而是完全发生在用户浏览器端。恶意脚本修改了页面的DOM结构，导致在客户端执行。例如，一个JavaScript函数直接从URL的hash部分读取数据并写入页面，如果hash值被篡改，就可能引发DOM型XSS。
那么，如何有效防御呢？
1. 输入验证与净化（Input Validation & Sanitization）： 这听起来像个老生常谈，但确实是第一道防线。在数据进入系统时，就要对其进行验证。例如，限制用户输入的长度、类型，不允许输入HTML标签等。但请注意，这只是一个初步的过滤，不能完全依赖它来防御XSS，因为攻击者总有办法绕过。
2. 输出编码（Output Encoding）： 这是防御XSS的核心。当用户输入的内容要展示到页面上时，必须根据其所处的上下文进行适当的编码。
-
HTML上下文： 将
<
,>
,&
,"
,'
,/
等特殊字符转义成HTML实体，例如<
变成zuojiankuohaophpcn
。function escapeHTML(str) { return str.replace(/[<>&"']/g, function (c) { return '&#' + c.charCodeAt(0) + ';'; }); } // 当要把用户输入放到 div.innerHTML = user_input 时，必须先进行编码 -
JavaScript上下文： 如果要把用户输入放到
如果CDN上的文件被攻击者替换或篡改，哈希值就会不匹配，浏览器将拒绝加载该资源。
5. 严格的输入白名单校验： 虽然前面提到了输入验证，但这里我想强调“白名单”的概念。与其尝试过滤掉所有可能的恶意输入（黑名单），不如只允许已知安全的输入通过（白名单）。这在处理富文本编辑器内容时尤其重要，可以只允许特定的HTML标签和属性。
6. HTTPS everywhere： 这已经不是什么新鲜事了，但其重要性不言而喻。HTTPS加密了客户端与服务器之间的通信，防止了中间人攻击窃听或篡改数据。虽然它不能直接防御XSS或CSRF，但它是所有前端安全实践的基石，没有它，很多防御措施的效果都会大打折扣。
总的来说，前端安全是一个持续演进的领域，没有一劳永逸的解决方案。我们需要不断学习新的攻击手段，并结合实际业务场景，灵活运用多种防御策略，才能构建一个相对健壮的安全体系。
