安全阶段讲了 Cookie、CORS、CSP、HSTS 四个机制。这一篇把它们串起来，从攻击视角看 Web 安全——这四个机制分别防的是什么攻击。
四大 Web 攻击速览
Web 安全有四大经典攻击，它们的攻击面不同，防御手段也不同：
- XSS（跨站脚本）：往页面注入恶意脚本。攻击的是「页面内容」。
- CSRF（跨站请求伪造）：借用户的登录状态发请求。攻击的是「身份凭证」。
- SQL 注入：往 SQL 里注入恶意片段。攻击的是「数据查询」。
- 点击劫持（Clickjacking）：用透明 iframe 诱导用户点。攻击的是「用户操作」。
逐个看它们怎么攻、怎么防。
XSS：注入脚本，浏览器分不清
前面 CSP 那篇详讲过。攻击者在评论区注入 <script>，浏览器把它当正常脚本执行，偷 Cookie、劫持操作。
防御是纵深三层：
- 输入转义（第一道）：把用户输入的
<、>转义成<、>，注入的 script 变成文本显示，不执行。这是根本防御。 - CSP（第二道）：万一转义漏了，CSP 限制脚本来源，注入的脚本加载不了。
- HttpOnly Cookie（第三道）：万一脚本执行了，Cookie 设了 HttpOnly，JS 读不到，偷不走。
三层任一层有效，攻击就失败。纵深防御的意义就在这——不依赖单点。
CSRF：借你的登录状态发请求
CSRF 的原理：你在 rubyfun.cn 登录了（浏览器存了 Cookie），然后访问 evil.com。evil.com 的页面里藏了一个表单或请求，指向 rubyfun.cn/delete-account，浏览器发请求时自动带上了你 rubyfun.cn 的 Cookie。服务器收到请求，看 Cookie 有效，以为是本人操作，执行了删除。
关键是「浏览器自动带 Cookie」——这就是第 21 篇说的「自动带」是风险来源。防御有三个：
- SameSite Cookie（第一道）：设
SameSite=Lax，跨站 POST 不带 Cookie。现代浏览器默认就是 Lax，挡住大部分 CSRF。 - CSRF Token（第二道）：服务器给每个表单一个随机 token，提交时要带。evil.com 不知道 token，伪造的请求带不上。
- 校验 Referer/Origin（第三道）：服务器检查请求来源，只接受本站来源。
注意 CSRF 和 XSS 的区别：CSRF 不需要注入脚本，它借的是「浏览器自动带凭证」；XSS 需要注入脚本执行。所以它们的防御手段不同——CSRF 靠 SameSite/Token，XSS 靠转义/CSP。
SQL 注入：拼接 SQL 的灾难
虽然不纯是 HTTP 层面，但它是 Web 最经典的攻击。攻击者在输入框里输入 ' OR 1=1 --，如果后端直接拼接 SQL：
SELECT * FROM users WHERE name = '' OR 1=1 --' AND password = '...'
OR 1=1 让条件恒真，-- 注释掉后面的密码检查，整个 users 表被读出来。
防御只有一个根本手段：参数化查询。用占位符 ? 让数据库区分「SQL 结构」和「数据」，输入再怎么怪也只是数据，不会被当 SQL 执行。不要手动拼接 SQL，这是铁律。
点击劫持：透明 iframe 诱导点击
点击劫持：evil.com 用一个透明 iframe 嵌入 rubyfun.cn 的「删除账号」按钮，上面盖一个诱人的「领奖品」按钮。用户以为在点奖品，实际点的是透明 iframe 里的删除按钮——借用户的手触发了本站的危险操作。
防御靠 X-Frame-Options 或 CSP 的 frame-ancestors：
X-Frame-Options: DENY—— 本页面禁止被 iframe 嵌入。Content-Security-Policy: frame-ancestors 'self'—— 只允许同源嵌入（CSP 的现代写法，替代 X-Frame-Options）。
这样 evil.com 就没法用 iframe 嵌入你的页面做点击劫持。
把防御机制串成一张图
回顾安全阶段讲的四个机制，现在能看清它们各防什么：
| 机制 | 防什么攻击 |
|---|---|
| HttpOnly Cookie | XSS 偷 Cookie |
| CSP | XSS 执行脚本 |
| SameSite Cookie | CSRF（跨站带凭证） |
| CORS | 跨域读响应（数据泄露） |
| HSTS | 降级攻击（中间人） |
| X-Frame-Options / frame-ancestors | 点击劫持 |
| 参数化查询 | SQL 注入 |
没有哪个机制是万能的，每个都针对特定攻击面。Web 安全是纵深防御——多层叠加，任一层有效就能挡住攻击。
收束：安全是 HTTP 的边界约束
安全阶段到此收尾。HTTP 本身是明文、无状态、开放的协议，这些特性让它灵活，也带来了安全风险。Cookie、CORS、CSP、HSTS、各种防御头，都是给 HTTP 加的「边界约束」——让它在不丧失灵活性的前提下，获得基本的安全保障。
下一篇进最后的演进与排障阶段——HTTP/2 怎么用多路复用和头部压缩解决 HTTP/1.1 的瓶颈，HTTP/3 为什么连 TCP 都换了。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 HTTP」，欢迎关注公众号 「十三Tech」。后续会按 URL 与报文、连接与传输、缓存与协商、安全与边界、HTTP/2 与 HTTP/3 这条线更新。
