跨站脚本攻击，也就是 XSS，是 Web 安全里最顽固的问题之一。它的本质是：攻击者把恶意内容混进数据，最终被浏览器当作可执行的代码运行，从而窃取信息或冒充用户。很多人以为防 XSS 就是"过滤掉危险输入"，但真正可靠的防线在另一头——在数据输出到页面时，根据它所处的上下文进行正确的编码。理解这个思路转变，是写出抗 XSS 代码的关键。
XSS 的本质：数据被当成了代码
XSS 的根源在于"数据"和"代码"的边界被突破。当一段本应是普通文本的用户输入，被浏览器解释成了 HTML 标记或脚本时，攻击就发生了。攻击者精心构造输入，让它在页面里"越界"成为可执行内容，于是别人的脚本就跑在了你的页面上。
理解这一点很重要：问题不在于输入里有特殊字符，而在于这些字符在输出时被赋予了语法含义。防御的目标，就是确保数据始终被当作数据，而不是代码。
为什么过滤输入不够
一个常见的误区，是寄希望于在输入端把"危险内容"过滤掉。但这条路走不通：你很难穷举所有危险形式，攻击者总能找到绕过的变体；而且同一段输入在不同的输出位置，危险性并不相同。过度过滤还会误伤合法内容，比如把用户名字里正常的符号也删掉。
更根本的是，输入时你往往还不知道这段数据将来会被放到页面的哪个位置。而危险与否，恰恰取决于那个位置。所以真正的防线必须放在输出端。
关键在输出，而非输入
正确的策略是：在数据被写入页面的那一刻，根据它将要进入的上下文，对它进行编码，把可能被解释成语法的字符转成无害的形式。这样，无论输入是什么，到了输出端都会被安然地当作纯文本对待。
这种"输出时编码"的做法之所以可靠，是因为此刻你确切知道数据要去哪里，从而能施加恰好正确的编码。把防御点从模糊的输入端，移到明确的输出端，是抗 XSS 思路的核心。
上下文决定编码方式
"正确的编码"并非只有一种，因为页面里有多种不同的上下文，每种对危险字符的定义都不一样。放在标签之间的普通文本、放在属性值里的内容、嵌进脚本里的数据、出现在 URL 中的部分——它们各自需要不同的编码规则。用错了上下文的编码，防护就会漏。
举例来说，对放在标签之间的文本有效的转义，未必能防住放进属性值或脚本里的注入。所以"上下文相关"这个词至关重要：你必须先看清数据落在哪个上下文，再选对应的编码方式。
几种典型上下文
实践中需要分别对待的上下文包括：HTML 正文，需要转义尖括号和和号等；HTML 属性，引号的处理尤为关键，否则可能提前闭合属性；JavaScript 内部，要防止数据破坏脚本结构；URL 部分，则需要相应的 URL 编码。每种上下文都有它特定的危险字符集合。
最棘手的是嵌套上下文，比如一段数据先进入属性、又在其中被当作 URL 或脚本使用。这类情形需要分层考虑，逐层施加正确的编码，否则任何一层的疏漏都可能被利用。
让框架替你做正确的事
好消息是，你通常不必手动处理所有这些编码细节。现代的模板引擎和前端框架，大多默认就对输出做上下文相关的编码，把用户数据安全地当作文本渲染。只要顺着框架的默认行为走，很多 XSS 风险就被自动挡住了。
真正危险的，往往是绕过这些默认保护的操作——比如直接把字符串当作 HTML 插入，或动态拼接脚本。这些"逃逸口"应当被当作高风险点来对待，能不用就不用，必须用时要格外谨慎地手动编码。
把编码放在正确的最后一步
归根结底，防范 XSS 的可靠之道，是把"按上下文编码输出"当成一条不可妥协的纪律。数据可以在系统里自由流动，但在它进入页面的最后一步，必须根据所处上下文被正确编码。这一步做对了，攻击者就无法让数据越界成代码。
记住三个要点：防线在输出端而非输入端，编码方式取决于上下文，尽量依赖框架的默认保护并警惕一切绕过它的操作。把这套思路内化为习惯，XSS 这个老大难问题就能被系统性地压制住。