XSS本质是浏览器执行了攻击者注入的恶意JavaScript代码，分反射型、存储型和DOM型三类；防御需输出编码、避免危险DOM操作、设HttpOnly Cookie及启用CSP。
XSS（跨站脚本攻击）本质是浏览器执行了不该执行的 JavaScript 代码——不是网站主动写的，而是攻击者把恶意脚本“塞”进页面里，借你的域名和用户权限偷偷运行。
三种常见注入路径
搞清楚脚本从哪来，才能堵住入口：
-
反射型：恶意代码藏在 URL 参数里（比如
search?q=），服务端没过滤，直接拼进 HTML 返回，一打开就执行。 - 存储型：攻击者把带脚本的评论、昵称、头像描述等存进数据库，之后每个访问该页面的用户都会自动执行——影响范围广，危害持续。
-
DOM 型：纯前端问题。比如用
location.hash或document.URL取值后，直接赋给innerHTML或通过eval()执行，服务器完全没参与，但脚本照样跑。
关键防御动作（不靠运气，靠机制）
防御不是“加个过滤”，而是分层卡点，每一步都默认不信任用户输入：
-
输出时强制编码：所有动态插入到 HTML 中的用户数据（比如评论内容、搜索关键词），必须做 HTML 实体转义：
替换，>替换>，"替换"。Java 用StringEscapeUtils.escapeHtml4()，JS 框架如 React 默认对{}内容转义，但注意dangerouslySetInnerHTML是例外。 -
避免危险 DOM 操作：不用
innerHTML、outerHTML、document.write()插入不可信内容；改用textContent显示纯文本，或setAttribute('src', url)设置属性——它们不会触发脚本解析。 -
设 HttpOnly + Secure Cookie：敏感 Cookie（如 sessionid）必须带
HttpOnly标志，让 JS 无法读取；加上Secure确保只走 HTTPS 传输。 -
启用 CSP（内容安全策略）：通过响应头
Content-Security-Policy: script-src 'self'明确禁止加载外部或内联脚本。哪怕 XSS 成功注入了标签，CSP 也能直接拦截执行。
别踩这些典型坑
很多漏洞不是技术不行，而是习惯性绕过防护：
立即学习“Java免费学习笔记（深入）”；
- 只在前端校验输入——后端必须重验，因为前端可被绕过；
- 用黑名单过滤（比如只删
script）——攻击者换成onerror=alert()或 Unicode 编码就能绕过； - 认为“管理员输入就安全”——管理员账号一旦失守，就是最高权限的 XSS 入口；
- 把 JSON 数据直接
eval()或innerHTML渲染——必须用JSON.parse()和安全 DOM API。
基本上就这些。XSS 防御不复杂，但容易忽略输出环节和 DOM 操作细节。守住“输入不过滤、输出必转义、Cookie 要隔离、策略要兜底”这四条线，就能挡住绝大多数真实攻击。
