跨站脚本

输入可以从请求参数、保存的内容或客户端状态等位置进入页面。关键是它最后被怎样解释：本来应作为文字的数据，若进入HTML、脚本或事件处理等活动上下文，就可能获得页面的执行能力，而不是继续只是供阅读的字符串。

“反射型”和“存储型”描述载荷怎样到达使用者，“服务端”与“DOM型”等又描述不安全处理发生的位置。OWASP特别指出这些分类会重叠，不能把它们当成三种彼此排斥、只要选择一种就能解释全部数据流的类别。

参考：[1]

普通文本节点可通过适当文本接口设置，不让浏览器重新把它当作HTML解析；但这要限定在普通元素，不能把脚本元素中的textContent也当成不会执行的文字区。接口名称相同，目标上下文不同，含义就可能改变。

若业务确实允许作者提供HTML，仅把所有内容转义会改变预期排版，这时需要合适的HTML净化和允许规则。HTML属性、URL、CSS和JavaScript字符串又各有解释方式，适用于一种位置的编码，不能自动作为另一种位置的安全证明。

参考：[2]

现代模板与框架可自动处理许多文本插入，但直接操作HTML或绕开默认保护的接口，会重新要求调用方负责上下文。净化后再由另一组件改写成活动内容，也可能破坏原有保证，必须沿实际数据流检查。

HttpOnly等Cookie属性能够限制某些数据读取，内容安全策略也可增加执行限制，却不自动清除注入缺陷。已在页面内执行的代码还可能以用户环境调用操作；因此防护目标不只是不让脚本读到Cookie，而是避免不可信数据取得页面代码权限。

参考：[2]