企业官网建设流程全解析

自建邮件服务里最容易被低估的攻击面，不是暴露在公网的 SMTP 端口，也不是 DNS 记录配错，而是用户每天要打开几十次的那个 Webmail 页面。它同时具备三个危险特征：渲染的是外部输入的 HTML、持有一个已登录的会话、并且就挂在主域名下面。XSS 和 CSRF 这两个老问题放到 Webmail 场景里，杀伤力会被成倍放大——前者能直接读走会话里的邮件内容，后者能让用户在完全无感知的情况下被改掉转发规则。这篇内容围绕 Mail-in-a-Box 这套自建邮件栈的 Webmail 安全加固展开，讲清楚邮件渲染管线在哪一层被拦截、nginx 与 PHP 与 Webmail 应用三层各自该守哪道门、配置项之间存在哪些互相打架的地方，以及改完之后怎么用一套可复现的流程去验证防护真的生效。适合已经跑起来一套自建邮件服务、正准备做一轮安全收敛的运维和开发者，也适合刚接手别人搭好的邮件服务器、想先摸清风险点在哪的人。

1. 一封"看起来很正常"的邮件，是怎么变成攻击入口的

1.1 邮件正文天生就是用户可控的 HTML

平时我们看网页，HTML 是站点自己写的，可控；看邮件，HTML 是外面任何人写好了发进来的，完全不可控。这个差别决定了 Webmail 从设计上就必须假设"每一封邮件的正文都是恶意载荷"。发信人只需要往你的服务器投递一封 MIME 结构正常的邮件，正文部分用text/html类型，里面塞什么标签由他决定。更麻烦的是，很多邮件客户端在转发、回复时会把原始 HTML 原样拼进新邮件，一封恶意邮件可以在一个组织内部循环传播很久。

除了正文，还有一批常被忽略的注入面：主题行（会显示在列表、通知、页面 title 里）、发件人显示名（From: "某某" <a@b.c>里那个引号内的部分）、附件文件名（尤其是中文名和超长文件名）、vCard 附件里的字段、用户自己写的 HTML 签名、联系人分组名。这些位置在渲染时如果少做一次转义，效果和正文注入是一样的。我在做审计的时候有个习惯：把所有"最终会出现在 DOM 里"的字段列一张表，逐个去代码里找对应的输出点，比漫无目的地翻模板效率高得多。

1.2 这套栈里到底谁在负责拦：三层责任划分

Mail-in-a-Box 这套东西的默认架构里，Web 请求要穿过三层才到浏览器：最前面是 nginx 做 TLS 终止和反向代理，中间是 PHP-FPM 跑 Webmail 应用，应用内部再有一套自己的 HTML 净化逻辑。三层都能加防护，但每层的职责边界必须划清楚，否则会出现"都以为对方管了"的空档。

我一般的划分是这样：nginx 层负责那些跟业务逻辑无关、纯 HTTP 语义的安全响应头，比如X-Content-Type-Options、Referrer-Policy、X-Frame-Options，以及一个兜底的 CSP；PHP 层负责会话本身的安全属性，cookie 的 HttpOnly、Secure、SameSite，还有会话存储路径和危险函数的收敛；应用层负责最核心的 HTML 净化策略和 CSRF token 校验。三层里应用层最难改也最不该乱改，nginx 和 PHP 两层是性价比最高的加固位置，改动小、见效快、回滚容易。

提醒一句：这三层不是简单叠加的关系。CSP 这种响应头如果在 nginx 和应用里各发一份，浏览器会按"多份策略取交集"处理，很容易把自己锁死到页面白屏。后面第 3 章会专门讲这个坑。

1.3 动手之前先把威胁模型写成清单

直接上去改配置是最容易出事的做法。我习惯先花半小时写一份两页纸的威胁模型，把"谁能打进来""打进来能拿到什么""我最怕丢什么"这三件事写清楚。对一套自建邮件服务来说，攻击者大致分三类：能往这个域投递邮件的外部人（成本极低，一封邮件即可）、已经拿到某个普通账号凭据的人（比如撞库成功）、以及能接触到同机器上其他服务的本地攻击者。

对应的资产也分三档：最高档是会话凭据本身，拿到就等于拿到邮箱全部历史邮件；第二档是邮件内容，包括重置密码邮件、发票、验证码；第三档是地址簿和日历，属于隐私泄露但不致命。威胁模型写完之后你会发现，防护优先级自然就出来了——所有配置改动都应该围绕"阻止攻击者在 Webmail 同源上下文里执行脚本"和"阻止跨站请求携带用户身份"这两条主线，其他都是锦上添花。

2. 追一遍渲染管线：XSS 从 MIME 到 DOM 之间被拦在哪个环节

2.1 从 maildir 里的原始报文到浏览器节点

想加固就得先知道数据是怎么流动的。一封邮件落到磁盘上，通常是 maildir 格式下的一个文件，里面是完整的 RFC 822 报文：头部、MIME 分隔符、base64 或 quoted-printable 编码的各段内容。Webmail 读取时先做 MIME 解析，拿到text/html那一段并解码，然后交给净化器处理，处理完的 HTML 片段被塞进页面的消息容器里，最后由浏览器解析成 DOM。

这条链路上有四个可以下手的位置：MIME 解析阶段（决定要不要把这段当 HTML 处理）、净化阶段（决定哪些标签和属性保留）、输出阶段（决定要不要再做一次实体编码）、浏览器阶段（CSP 决定即使有漏网的脚本能不能执行）。绝大多数历史漏洞都出在第二和第三个位置，也就是净化器的规则不够严，或者某条代码路径绕过了净化器直接输出。最后一个位置 CSP 是唯一能在前三个位置都失守时兜底的机制，这也是为什么我一直强调 CSP 不能省。

2.2 净化器的能力边界：哪些标签它能处理，哪些它照单全收

主流 Webmail 用的净化策略基本都是白名单思路：维护一份允许的标签和属性列表，不在列表里的一律剥掉，同时把on*事件属性、javascript:伪协议这类东西清掉。这套思路本身没问题，问题往往出在边界上。我实测下来，容易出事的几类构造包括：SVG 命名空间里的<script>（很多基于正则的净化器认不出来）、<math>标签里的属性、srcdoc属性里的完整 HTML 文档、以及 CSS 里的url(javascript:...)老写法。

还有一类是"属性值二次解析"的问题。比如href属性被净化器检查过，确认不是javascript:，但某些浏览器对前后空白字符、控制字符、HTML 实体编码的处理不一致，javascript:这种写法在某些历史版本上能绕过检查。这类绕过层出不穷，指望净化器做到 100% 是不现实的，这也是为什么必须把 CSP 作为第二道防线而不是可选项。

2.3 为什么"过滤用户输入"这条路在邮件场景里走不通

很多从 Web 开发转过来的人第一反应是"在入口处把危险字符过滤掉"。这个思路在邮件场景里完全不成立，原因有三个。第一，邮件的输入方是全世界，你没法给所有人定规则；第二，过滤会破坏正常邮件，很多正规邮件本来就带复杂 HTML 和样式，过滤过头用户会投诉；第三，也是最关键的，邮件内容在存储和转发过程中可能被多次编码解码，你在入口过滤的字符串和最终渲染的字符串根本不是同一个东西。

正确的思路只有一条：不在存储侧做任何"清洗"，原样保存；在输出侧做严格的上下文相关编码和白名单净化；再用 CSP 作为最后兜底。这个顺序不能乱，一旦在存储侧做了破坏性清洗，用户丢邮件内容和排查问题都会变得极其痛苦——我曾经接手过一套被前任管理员加了"入库前删 script 标签"的服务，结果用户收到的代码类邮件全部变形，最后只能从备份恢复。

3. 三层配置改法：nginx、PHP、Roundcube 各自该守哪一道门

3.1 nginx 层：CSP 与几个必加的安全响应头

nginx 这层的改动最安全，因为不涉及应用逻辑。先加一批没有争议的头：X-Content-Type-Options: nosniff阻止浏览器猜 MIME 类型（这对防止把上传的文本文件当 HTML 执行很关键）、X-Frame-Options: SAMEORIGIN防点击劫持、Referrer-Policy: same-origin防止用户点开邮件里的外链时把带参数的 URL 泄露给第三方站点。最后这个头特别值得加，因为 Webmail 的 URL 里经常带邮箱名、消息 UID 这类参数。

CSP 要谨慎。我建议先用Content-Security-Policy-Report-Only跑一到两周，收集违规报告，确认没有误伤正常功能之后再切成强制模式。一个相对宽松但仍有价值的起点是这样：

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; frame-ancestors 'self'; base-uri 'self'; form-action 'self'; report-uri /csp-report;" always;

这里保留'unsafe-inline'是因为多数 Webmail 版本大量使用内联事件和内联脚本，直接去掉会白屏。虽然削弱了防护，但frame-ancestors、base-uri、form-action这几条依然生效，能挡住点击劫持和表单劫持。等确认应用版本支持外链脚本之后，再逐步收紧。

坑点：add_header在 nginx 里有继承陷阱——如果某个location块里也写了add_header，父级的头会全部失效。Webmail 通常有多个 location（静态资源、上传、API），改完务必用curl -I对每个路径单独验证一遍响应头是否都在。

3.2 PHP 层：会话 cookie 属性与危险函数收敛

PHP 这层主要管会话。默认的 PHP 会话配置在共享环境里问题不少，即便这是台专用机器，也值得收一遍。核心几项：session.cookie_httponly = 1让 JS 读不到会话 cookie，这是 XSS 场景下最后一道隔离；session.cookie_secure = 1保证 cookie 只在 HTTPS 上传输；session.use_strict_mode = 1防止会话固定攻击，服务端会拒绝客户端自己生成的未知 session id；session.use_only_cookies = 1禁止 URL 里传 session id。

session.cookie_samesite建议设成Lax而不是Strict。Strict更安全，但从外部链接点进 Webmail 时首跳不带 cookie，用户会看到一次"未登录"的错觉，体验很差，而且很多人会因此去点"重新登录"，反而增加钓鱼风险。Lax在跨站 POST 上依然不带 cookie，对 CSRF 的防护效果已经足够。

session.cookie_httponly = 1 session.cookie_secure = 1 session.cookie_samesite = "Lax" session.use_strict_mode = 1 session.use_only_cookies = 1 session.sid_length = 48 session.sid_bits_per_character = 6 expose_php = Off

另外两个容易漏的点：一是把session.save_path指到一个专用目录，别用默认的/tmp。同机器上如果还有别的 PHP 应用，/tmp是共用的，虽然会话文件权限通常是 600，但同用户下的其他进程能读，隔离一下更稳妥。二是确认上传目录和临时目录里禁止执行 PHP，路径匹配规则写进 PHP-FPM 的配置里，别只依赖 nginx 的 location 匹配。

3.3 Roundcube 层：让"用户偏好"不能绕过安全策略

应用层的配置文件是最需要小心的，因为 Mail-in-a-Box 的安装脚本会在每次运行时重新生成主配置。动手之前先确认你改的那个文件会不会被覆盖，如果会，就把自定义项放到一个安装脚本不碰的独立文件里，再在主配置末尾引入它。

几个必须确认的配置项：

dont_override是最容易被忽略的一项。它接受一个配置项名称数组，列在里面的项用户在偏好设置界面改不了。如果不设，用户完全可以自己进设置页把"显示远程图片"打开，你前面所有努力白费。我一般至少锁这几项：

$config['dont_override'] = [ 'show_images', 'htmleditor', 'preview_pane', 'message_highlight', 'identities_level', 'client_mimetypes', ];

identities_level建议设成 1（允许改显示名但发件地址固定），防止有人拿你的服务器伪造任意发件人。ip_check开启后移动网络切换基站会掉线，这是安全性和体验的取舍，内部办公场景建议开，面向大量移动用户的场景可以关掉但要把会话有效期调短。

4. 附件才是重灾区：SVG、HTML 附件与预览链接的绕过路径

4.1 SVG 为什么能带着脚本跑进同源上下文

在所有需要重点盯防的文件类型里，SVG 是最阴的一个。它本质上是 XML，可以内嵌<script>和事件属性，但它的 MIME 类型是image/svg+xml，很多系统把它归类成"图片"直接内联显示。一旦浏览器以顶层文档或 iframe 的方式加载了这个 SVG，里面的脚本就在你的域名下执行了，同源策略完全保护不了你。

防法有两个层次。第一层是 MIME 映射表，把svg从"可内联预览"的图片列表里拿掉，改成强制下载，或者用一个独立的、不带任何会话 cookie 的子域来提供附件预览。第二层是 nginx 的Content-Disposition: attachment加上X-Content-Type-Options: nosniff，保证浏览器不会自作主张当成 HTML 渲染。第二层是兜底，即使应用层判断错了，浏览器也不会执行。

我见过一个很典型的问题：附件预览功能把文件写到临时目录，然后用一个带签名参数的 URL 返回给前端，用户点开时浏览器按扩展名猜类型。一个叫invoice.html的附件被直接当成网页打开了，里面一段脚本读走了同域的 cookie。修法不止是加Content-Disposition，还得让临时文件的存放路径和 Webmail 主站不同源。

4.2 附件下载路径与临时目录的权限边界

临时目录这个话题值得单独说。Webmail 处理大附件时通常要先落到磁盘上，这些临时文件的生命周期很短，但如果路径在 Web 根目录下面，或者能被直接 URL 访问，就等于开了一个任意文件写入转执行的通道。需要确认三件事：临时目录不在 Web 根下、临时文件权限是 600、目录里有.htaccess或者 nginx 层面禁掉所有脚本执行。

location ^~ /webmail/temp/ { deny all; return 403; }

如果临时目录必须对外提供下载（比如附件预览接口），那就用internal指令只允许内部跳转，外部直接访问一律拒绝。这样即使有人猜到了文件名，也拿不到内容。

4.3 MIME 映射表该怎么改

配置文件里的 MIME 映射表决定了什么类型能内联显示、什么类型只能下载。原则很简单：只有确定安全的位图格式（jpeg、png、gif、webp）和内联文本才允许预览，其余一律下载。HTML、SVG、XML、JS、PDF（PDF 有历史漏洞）全部走下载路径。

$config['mime_types'] = [ 'htm' => 'text/plain', 'html' => 'text/plain', 'svg' => 'application/octet-stream', 'xml' => 'text/plain', 'js' => 'text/plain', ];

注意这里把 HTML 映射成text/plain而不是简单禁掉，目的是让用户还能看内容，只是以纯文本形式看，不会执行。用户体验上比直接拒绝好很多，投诉会少一半。改完之后一定要用测试邮件把每种附件都发一遍实测，别只看配置觉得没问题。

5. CSRF 这条线：token 机制本身没问题，配错的往往是旁边那几项

5.1 request token 在请求生命周期里怎么走

主流 Webmail 的 CSRF 防护用的是同步令牌模式：会话建立时生成一个随机 token 存进 session，所有表单渲染时把它作为隐藏字段塞进去，提交时服务端比对。AJAX 请求则通过自定义请求头传递，因为自定义头跨站是加不上去的——浏览器对非简单请求会先发预检，而攻击者控制的站点拿不到预检通过。这一套设计本身没问题，问题几乎全出在实现细节上。

最常见的三个错：一是某些接口忘了调校验函数，或者是可选校验（返回布尔但不中断），开发者以为校验了其实没有；二是 token 在会话续期时没刷新，或者刷新了但页面上的旧 token 还留着；三是登出、密码修改这类高价值操作走了独立的处理路径，压根没接进统一的校验流程。我排查这类问题的方法很笨但很有效：把所有会改变服务端状态的 action 名字列出来，逐个构造无 token 的请求打一遍，看哪些返回了 200。

5.2 SameSite 取值与自建面板的实际取舍

SameSite 是浏览器层面的兜底。设成Lax之后，跨站的 POST、PUT、DELETE 请求一律不带 cookie，绝大部分 CSRF 攻击直接就废了。但它不能替代服务端 token，因为Lax对顶层 GET 导航是放行的，如果某个状态变更操作被错误地实现成了 GET（这在老代码里很常见，比如"点链接直接退订"），Lax拦不住。

Strict更彻底，但前面说过会给用户造成"从外链进来要重新登录"的困扰。我的实际选择是：面向内部、访问入口固定的场景用Strict；面向不确定来源的场景用Lax加严格的服务端 token。另外 Nort：SameSite属性只在 cookie 的域名与当前站点是同站时生效，如果你有多个子域交叉访问，得先理清哪些算同站。

5.3 登出、偏好保存、外部回调这些容易被漏掉的入口

耗子往往出在这几个地方。登出接口如果只接受 GET 且不校验 token，攻击者可以在页面里塞一个<img src="https://mail.example.com/?_task=logout">，用户浏览任意页面时就被登出了——危害不大但很烦人，而且可以被用来配合社工。偏好设置保存接口如果只校验了部分字段，攻击者可以构造请求把"自动转发"打开，这是真实世界中最值钱的 CSRF 利用方式之一。

还有一类是第三方集成回调。日历订阅、地址簿同步、OAuth 回调这类接口，通常要处理外部发起的请求，为了兼容性往往放宽了校验。这类接口必须做三件事：校验state参数、校验Origin/Referer、限制回调 URL 白名单。少一样就等于开了个后门。

// 示例：统一的状态变更请求校验入口 function require_valid_request() { if ($_SERVER['REQUEST_METHOD'] === 'GET') { http_response_code(405); exit; } $token = $_POST['_token'] ?? $_SERVER['HTTP_X_REQUEST_TOKEN'] ?? ''; if (!hash_equals($_SESSION['request_token'] ?? '', $token)) { http_response_code(403); exit; } }

这段代码没什么花哨的，但重点是"统一入口"这四个字——所有状态变更操作都必须先过它，不允许任何例外。我在代码评审时会把这条当成硬性红线。

6. 改完必须验证：一套能在隔离环境里跑通的测试流程

6.1 造 payload 邮件与发信脚本

加固做完了不代表生效了，必须实测。最省事的办法是在本地或隔离环境里起一套同样的服务，用脚本往测试账号发一批构造好的邮件。发信部分用 Python 的 smtplib 十几行就能搞定，关键是 payload 要覆盖不同注入位置。

import smtplib from email.mime.text import MIMEText from email.header import Header payloads = [ ('<img src=x onerror=alert(1)>', '正文事件属性'), ('<svg><script>alert(1)</script></svg>', 'SVG命名空间'), ('<a href="javascript:alert(1)">click</a>', '伪协议'), ('<iframe srcdoc="<script>alert(1)</script>"></iframe>', 'srcdoc'), ('<math><mtext><script>alert(1)</script></mtext></math>', 'math标签'), ] for body, name in payloads: msg = MIMEText(body, 'html', 'utf-8') msg['Subject'] = Header(f'XSS测试-{name}', 'utf-8') msg['From'] = 'tester@example.com' msg['To'] = 'victim@example.com' with smtplib.SMTP('127.0.0.1', 25) as s: s.send_message(msg)

除了正文，还要单独测主题行注入（把 payload 放在 Subject 里）、发件人显示名注入（From: "payload" <a@b.c>）、附件文件名注入（filename="<script>..."）。这三个位置在很多实现里是分开渲染的，正文防住了不等于它们也防住了。

6.2 用响应头和 CSP 违规事件判断防护是否真的生效

打开浏览器开发者工具，先看 Network 面板里主文档的响应头，确认Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Referrer-Policy四项都在，且值符合预期。然后打开其中一封 payload 邮件，看 Console 面板——如果 CSP 生效，会看到Refused to execute inline script之类的违规日志，同时页面上不应该有弹窗。

这里有个细节：弹窗没出现不等于防护生效，也可能是净化器先把标签删了。要看 DOM 里最终渲染成什么样，用 Elements 面板搜索一下onerror、<script，确认这些内容要么被删掉、要么被转义成文本。如果标签还在但脚本没执行，说明是 CSP 起的作用，这种情况要特别注意——净化器这层其实是失守的，只是被兜底了，后续升级时不能把 CSP 去掉。

6.3 无 token 请求的手工复现与回归清单

CSRF 部分的验证用 curl 就够。先登录拿 cookie，然后构造一个不带_token的 POST，看服务器返回什么。正确的行为应该是 403 或者明确的重定向。

curl -i -b cookies.txt \ -X POST 'https://mail.example.com/?_task=settings&_action=save-prefs' \ -d 'show_images=1'

如果返回 200 并且偏好真的被改了，说明这个接口没接校验。把这类请求打进一个脚本批量跑，覆盖所有状态变更 action，形成一份回归清单。下面这张表是我自己用的最小检查集：

这张表建议每次升级后都重跑一遍，升级引入回归是常有的事。

7. 一次排查复盘：用户点开某封邮件后页面被跳走

7.1 现象与第一轮排除

某公司内部一套自建邮件服务，有用户反馈"点开某封邮件之后页面自己跳到了别的网站"。这种描述听起来像 XSS 打到了跳转，但也可能是邮件内容里就是个正常的短链接。第一轮要做的排除工作：让用户把那封邮件以 .eml 格式导出来（原始报文比截图有用一万倍），同时把页面 URL、跳转目标域名、发生时间一起记录下来。

拿到 .eml 之后先看结构。用文本编辑器打开，找Content-Type: text/html那一段，如果是 base64 或 quoted-printable 编码的，先解码。这一步能过滤掉一大半误报——很多时候就是邮件里一个很显眼的"点击查看"按钮，用户以为是被劫持了。这次的情况不是，解码后的 HTML 里有一段很可疑的<a href后面跟着一长串看起来像编码过的东西。

7.2 从日志和报文里找到注入点

把可疑片段单独拿出来在测试环境渲染。渲染后 DOM 里发现，href属性里的内容被净化器处理过，javascript:前缀被剥掉了，但留下了一个畸形的data:text/html;base64,...形式的链接，点击后会在当前域打开一个 attacker 控制的页面。这是一个典型的净化器覆盖不全的问题——它处理了javascript:协议，但没处理data:协议。

再往下查，为什么用户"点开邮件就跳走"而不是"点击才跳走"。查 nginx 访问日志，发现这个用户的会话在那封邮件打开的时间点之后有几个异常的 POST 请求，参数里带了对外转发地址。结合应用日志，确认是页面里还有一段<meta http-equiv="refresh">被保留了下来。这就严重了：meta refresh不需要用户交互就能跳转，跳转目标页里再执行一段脚本，整个链路就串起来了。

7.3 修复、批量清扫与后续监控

修复分三步。第一步是补净化器规则，把data:协议和meta refresh加入黑名单——这一步要打补丁，升级前先临时在 nginx 层加一层 CSP 阻断。第二步是批量清扫：如果这是一封群发邮件，可能已经投递到了很多人的收件箱。用 grep 在 maildir 里按特征串扫一遍，把命中的邮件标记出来，通知用户不要打开，或者用脚本直接移到隔离目录。

grep -rl --include='*' 'data:text/html;base64' /home/user-data/mail/mailboxes/ 2>/dev/null | head -50

第三步是加监控。在 nginx 日志里加一条告警规则：某个用户会话在短时间内连续出现带外部域名的 POST，或者响应体里出现了不该出现的Content-Security-Policy违规上报。这类信号比事后排查有效率得多。

8. 运维层面的几个长期习惯

8.1 安装脚本会覆盖配置，这件事必须提前设计

Mail-in-a-Box 这类一体化部署工具最大的便利是"一条命令装完"，最大的麻烦也是"一条命令可能把你改过的东西冲掉"。主配置文件由安装脚本生成，每次升级或重跑都会重写。所以任何自定义的安全配置，从一开始就要设计成"不被覆盖"的形态。

我通常的做法是：找一个安装脚本不碰的文件（很多应用支持在主配置里 include 一个额外的本地配置文件），把所有的加固项写进去。如果应用不支持这种机制，就写一个幂等的小脚本，每次升级后跑一遍，用sed或者模板重新注入关键项，并且脚本自己在最后做一次校验，确认关键配置项的值符合预期。再退一步，至少要用版本管理工具盯住那个文件，改完立刻提交，升级后跑一次diff就知道有没有被冲掉。

8.2 插件与皮肤：升级时最该盯的两处

第三方插件和皮肤是新注入面的高发区。插件为了扩展功能，往往要往页面里注入自定义 HTML 和 JS，很多插件作者并没有做严格的转义；皮肤则是整套模板，一旦被替换，所有输出点的转义逻辑都变了。我的原则是：只保留确实在用的插件，其余全部禁用；皮肤只用官方发行的，不做任何自定义修改。

升级时要特别留意插件版本和主程序的兼容性。有些老插件在新版本主程序上会静默失效，功能看起来还在，但里面的安全校验已经不对了。升级完成后，把第 6 章那张回归清单重跑一遍，能挡掉大部分问题。

8.3 日志里值得长期保留的几条线索

日志不要只看错误。有几个信号我建议常驻监控：一是同一账号在短时间内出现大量登录失败，这是撞库的典型特征；二是某个会话突然开始访问平时不访问的功能（比如从来没进过设置页的账号突然连续调用偏好保存接口），这可能是会话被劫持后的横向探测；三是 CSP 违规上报突然增多，意味着要么有新漏洞在被利用，要么你刚改的规则误伤了正常功能。这三条线索的成本很低，但真出事的时候能帮你把排查时间从几小时压缩到几分钟。

最后分享一个我自己踩过的小坑：改 CSP 的时候我为了省事直接在生产环境上切了强制模式，结果有用户的邮件签名里带了一段内联style，规则里没放行，导致签名全部错乱，半小时内收到了十几条反馈。从那以后我所有的 CSP 改动一律先走 Report-Only，至少观察三天，看上报量的曲线平稳了再切。这套流程看起来慢，但比出事后回滚快得多。