html制作Report-To错误报告_html Report-To报告端点安全事件收集【技巧】-html教程-PHP中文网

report-to 必须由服务端通过 http 响应头返回，html 中的 meta 标签无效；需与 csp 的 report-to 组名严格匹配，且 endpoint 必须 https 并返回 2xx。

html制作report-to错误报告_html report-to报告端点安全事件收集【技巧】

Report-To 响应头必须由服务端返回，不能写在 HTML 里

浏览器完全忽略 <meta http-equiv="Report-To"> 标签——这是最常踩的坑。Report-To 是 HTTP 响应头，不是 HTML 属性或 meta 指令，reportError() 或 CSP 都不会读取它。

验证是否生效：打开 DevTools → Network → 刷一次页面 → 点开任意 HTML 请求 → 查看 Response Headers 里有没有 Report-To 字段。没有就说明后端没配，整个链路从第一步就断了。

Nginx 示例：add_header Report-To '{"group":"csp-report","max_age":31536000,"endpoints":[{"url":"https://your.domain/reports"}]}';
Express 示例：res.set('Report-To', '{"group":"csp-report","max_age":31536000,"endpoints":[{"url":"https://your.domain/reports"}]}');
值必须是合法 JSON 字符串（双引号、无注释、无换行），顶层必须是对象，不是数组

CSP 的 report-to 必须与 Report-To 中的 group 名严格一致

光有 Report-To 头还不够。浏览器不知道该对哪些事件启用上报，得靠 CSP 显式绑定。如果组名不匹配，CSP 违规等事件会静默失败，Network 面板里根本看不到 POST 请求。

比如 Report-To 里写了 "group":"csp-report"，那么 CSP 必须包含 report-to csp-report；如果 Report-To 没写 group，默认就是 default，CSP 就得写 report-to default。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

错误写法：Content-Security-Policy: script-src 'self'; report-to csp-violation;（但 Report-To 里是 "group":"csp-report"）
正确写法：Content-Security-Policy: script-src 'self'; report-to csp-report;
不要混用 report-uri：Chrome 98+ 已彻底弃用，写了也白写，还会干扰调试

reportError() 是唯一能让 JS 错误走 Reporting API 的标准方式

Reporting API 默认不上报 TypeError、ReferenceError 或 unhandledrejection——它只处理内核级事件（如 CSP、证书、混合内容）。想让 JS 错误进这个管道，必须主动调用 reportError()，且仅 Chromium 114+ 支持。

关键约束：只能传 Error 实例，不能传字符串、普通对象或 e.message，否则静默丢弃；目标 endpoint 必须支持 CORS（Access-Control-Allow-Origin: *），否则请求被拦截且无任何提示。

推荐写法：window.addEventListener('error', e => { if (e.error && typeof reportError === 'function') reportError(e.error); });
注意：e.error 是标准 Error 对象；throw new Error('xxx') 不会自动触发，必须捕获后手动传入
上报类型固定为 default，结构由浏览器封装，后端需按 {"type":"default","age":...,"body":{...}} 解析

上报 endpoint 必须是 HTTPS，且响应状态码必须为 2xx

Chrome 当前强制要求 endpoint 使用 HTTPS 协议，HTTP 地址会被直接拒绝；同时，浏览器发送报告后，如果收到非 2xx 响应（比如 404、500、302），整个 Reporting API 功能会降级为禁用——后续所有报告都不再发出，且控制台不报错。

这意味着 endpoint 不只是“能收”，还得稳定可靠。常见翻车点：Nginx 反向代理没透传响应码、Lambda 函数超时返回 502、WAF 拦截 POST /reports 路径。

调试建议：用 curl -X POST -H "Content-Type: application/reports+json" -d '{}' https://your.domain/reports 手动测试 endpoint 是否可写、是否返回 2xx
如果用了 Service Worker，检查 fetch 事件是否意外过滤或阻塞了 /reports 路径
多个 endpoint 可通过多个 Report-To 响应头配置，但每个都必须满足 HTTPS + 2xx 条件

真正难的不是拼出那几行 JSON，而是确认浏览器发出了请求、你的服务器收到了、并且没在中间某层被静默吞掉。尤其当 report-to 请求只在真实违规时触发，日常开发几乎看不到它——你得主动制造 CSP 违规或证书错误来验证整条链路。