跨站脚本攻击（XSS）可以说是 Web 安全中最基础、也最常见的一类安全漏洞。简单理解，就是攻击者通过某种方式把恶意代码注入到网页内容中，当其他用户访问该页面时，这段代码会在用户浏览器里执行，相当于“借用”用户当前的身份和权限去实施恶意操作。造成的后果往往比较严重，例如篡改用户数据、窃取敏感信息，甚至还能为后续攻击（如 CSRF）创造条件。从本质上看，XSS 攻击就是将恶意 HTML 或 Ja vaScript 强行插入正常页面中，用户一旦打开页面，恶意脚本就会自动运行。
跨站脚本攻击的解决思路
防御 XSS 漏洞，最核心的思路其实只有一句话：任何输出到 HTML 页面中的数据，都必须进行 HTML 转义。这是 Web 安全防护中非常基础、但也极其有效的一种方法。
举个常见例子，假设有一段 PHP 代码如下：
如果这里的 $articleText 来自用户输入，那么攻击者完全可以构造一段包含恶意 Ja vaScript 的内容，最终页面输出就可能变成下面这样：
这段内容一旦被浏览器解析和渲染，弹窗就会立即出现。当然，这里只是用弹窗做演示，实际危害远不止如此。攻击者完全可以借助一段 Ja vaScript 代码去修改用户资料、盗取 Cookie 信息，甚至进一步发起其他 Web 攻击，后果会更加严重。
解决方案其实并不复杂，就是对输出的数据做 HTML 转义。转义之后，输出内容会变成这样：
这样处理之后，原本可能执行的恶意代码都会以普通文本的形式展示出来，浏览器不会再把它当成脚本执行，自然也就达到了防止 XSS 攻击的目的。
XSS 危害
XSS 这种攻击方式，说起来有点像“门槛不低、影响却很广”的典型 Web 漏洞。说它门槛不低，是因为实际利用往往比较耗时，成功率不一定高，很多场景下也不容易自动化，同时还要求攻击者对 HTML 和 Ja vaScript 有较好的理解。但它之所以在网络安全领域始终热门，是因为这类漏洞实在太常见了——哪怕是一些大型互联网平台或成熟网站，也可能因为一个细节疏漏而留下 XSS 安全隐患。漏洞分布广泛，关注度自然一直居高不下。
事实上，不管是哪一种 XSS 攻击类型，核心原理都离不开一点：让攻击者控制的 Ja vaScript 在目标页面中执行。因此，只要始终坚持一个基本安全原则——后端永远不要信任前端提交的任何数据，并且无论输入处理还是输出展示，都严格做好 HTML 转义和必要校验，那么 XSS 漏洞通常就很难真正形成威胁。
跨站请求伪造攻击 (CSRF)
跨站请求伪造（CSRF）也是一种非常常见的 Web 安全攻击。攻击者会尽可能伪造一个看起来合法的请求，模拟用户提交表单或调用接口的行为，从而实现修改用户数据、执行敏感操作或触发特定业务请求等目的。
在真实攻击场景中，CSRF 往往会和 XSS 组合使用：先利用 XSS 获取用户身份相关信息，再进一步发起 CSRF 请求，从而达到“冒充用户操作”的效果。
解决思路
那么，如何有效防御 CSRF 攻击呢？通常主要有两个思路。
第一，提升攻击的实现难度。GET 请求天然更容易被伪造——用户点击一个链接，就可能无意间发起一个 GET 请求。相比之下，POST 请求伪造起来更麻烦，攻击者通常还需要结合 Ja vaScript 等方式才能完成。因此，让表单提交或服务端敏感接口只接受 POST 请求，能够明显提高系统抵御 CSRF 的能力。
第二，对请求进行身份认证，确保当前请求确实由用户本人发起，而不是第三方恶意伪造的。正常用户提交表单的标准流程通常如下：
- 用户点击链接 → 网站显示表单 → 用户填写内容并提交 → 网站接收数据并保存
而 CSRF 攻击的流程，往往会直接绕过“展示表单”这一步：
- 攻击者直接伪造提交信息 → 网站接收攻击者篡改后的数据并保存
只要能够有效区分这两种请求来源，就可以大幅降低 CSRF 漏洞带来的风险。具体做法是什么呢？关键就在于校验提交请求中的关键信息，确认这些数据确实来自网站最初展示给用户的那个表单。常见验证流程如下：
- 用户点击链接 → 网站显示表单，表单中包含一个特殊的 token，同时把这个 token 保存在 session 中 → 用户填写信息并提交，同时把 token 一并发送回服务端 → 网站比对用户提交的 token 与 session 中保存的 token，只有完全一致时，才接收数据并保存
这样一来，即使攻击者成功伪造了请求，也无法获取用户当前 session 中对应的 token 值。请求到达服务端后，token 验证无法通过，自然就会被直接拦截。这个防御机制实现起来并不复杂，但在防止 CSRF 攻击方面通常非常有效。
