授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、先分清 CSP 管的是「加载」还是「执行」1.1 两行一模一样的头两个不一样的结果先说一个具体的场面。有人在自建靶场里给站点加 CSP加得很朴素nginx 里多写一行add_header。加完打开两个页面A 页面图表区整块白了B 页面同一个模板图表正常。他把两边的响应头抓下来逐字比对那一行完全相同。头一样结果不一样于是他判断是浏览器实现有差异。这个判断是错的而错的地方不在浏览器。差别在 B 页面的模板里——那是一份旧模板里面还留着一条script-src。因为这条script-src存在A 页面那行default-src在 B 页面对脚本请求的判定里根本没有参与。它不是总开关只填空缺同一条头给出两种结果不是浏览器不一致是两条策略里「空缺」的位置不同。出处先说清本文引用 W3C《Content Security Policy Level 3》。截至 2026-10-25它的状态是W3C Working Draft日期 2026-09-16地址https://www.w3.org/TR/CSP3/。它是工作草案不是 Recommendation条文还会改所以本文每处原文只对 2026-09-16 这一版负责。1.2 一条策略里混着四种东西很多人把 CSP 当成一份资源白名单。这个印象在早期版本勉强够用放到 Level 3 就不够了一条策略里的指令按作用对象至少分成四类。类别管的问题本文涉及的指令有default-src兜底吗fetch 指令某一类请求能不能发出去script-src-elem、script-src-attr、img-src、connect-src、font-src、object-src有文档指令文档自身的某些行为受不受限base-uri、sandbox没有导航指令谁能嵌我、我能往哪里提交frame-ancestors、form-action没有上报指令违规信息往哪里送report-uri、report-to没有最右一列是全文的骨架只有第一类有兜底后三类没有。default-src的覆盖范围比多数人以为的窄得多——它只管「请求发不发得出去」不管「这份文档能不能被嵌」。分类不是按危险程度分的是按判定发生在哪一刻分的fetch 指令在请求发起前判定手里有一个目标 URL 可比对导航指令没有这个 URLframe-ancestors判的是「能不能被某个祖先嵌进去」也就无从兜底。1.3 「我加了 CSP」这句话本身没有信息量要判断一条 CSP 在做什么至少问清三件事。加在哪里。响应头还是meta元素——meta装不下某些指令第六章。加了几条。一个响应可以有多条策略头多条之间不是「后一条覆盖前一条」第三章。每条里写了哪些指令。写了哪几条 fetch 指令剩下的才轮到default-srcnone那处的列表是否真为空Report-Only 那条是否根本没在拦第二、五、四章。少问一个结论就可能反过来。本章可以带走的一句CSP 不是一份资源白名单而是按请求类型分开判的一组规则说「我加了 CSP」信息量等于零。二、误解一把default-src当成总开关2.1 「no inheritance」这五个字要读三遍规范讲这件事只用了一句话位置很不起眼但它是否掉后面一半误读的钥匙There is no inheritance. If a script-src directive is explicitly specified, for example, then the value of default-src has no influence on script requests.两个词要抓住。no inheritance这里没有继承。has no influence不是影响变小不是优先级更低是没有任何影响。我们平时说「默认值」模型是继承子级没写用父级写了用自己父级还在那儿放着。CSP 不是这个模型它是填表没填的格子default-src帮你填上填过的它连看都不看。Content-Security-Policy: default-src self; script-src https://cdn.example.com⚠️代码待验证这条策略有两处容易读错。第一script-src这一格被填过了default-src从此不参与脚本判定。脚本的放行范围只有「https://cdn.example.com」self不在里面——它不允许加载同源脚本。写它的人想的是「同源照旧再加一个 CDN」按规范语义做的是「把脚本源换成 CDN 一个域」。第二default-src剩下的权力还在图片、字体、样式、连接、媒体、对象没被单独填仍由它兜着。所以在本条策略内部再写一条script-src是替换不是叠加。这和「多写一条更保险」的直觉正好相反。2.2 规范给的等价写法里没有script-srcdefault-src self等价于什么规范直接给了展开式值得原样抄一遍Content-Security-Policy: connect-src self; font-src self; frame-src self; img-src self; manifest-src self; media-src self; object-src self; script-src-elem self; script-src-attr self; style-src-elem self; style-src-attr self; worker-src self⚠️代码待验证一共 12 项序号等价清单里的指令它管的是哪一类请求1connect-src脚本发起的连接XHR、WebSocket 这一类2font-src字体文件3frame-src这一页里嵌进去的子框架4img-src图片5manifest-srcWeb App Manifest6media-src音频与视频7object-src插件类对象8script-src-elem脚本元素9script-src-attr元素上的内联脚本属性10style-src-elem样式元素11style-src-attr元素上的内联样式属性12worker-srcWorker 类脚本有一个必须原样保留、不能「顺手改对」的细节清单里是script-src-elem和script-src-attr不是script-src是style-src-elem和style-src-attr不是style-src。因为在这套判据里「脚本」本来就不是一个东西是两个脚本元素和内联脚本属性走两条判定路径各有各的指令。script-src不在清单里是因为它在这套结构里统管这两者不是被统管的一项——把它展开进清单会把两层压成一层。实际影响有两处。想单独管住内联脚本属性有专门的指令可用不必动整体。排查时看报告里的effective-directive写script-src-attr说明问题出在属性上写script-src-elem才是脚本元素改法完全不同。script-src与这两条如何回落需要另开一篇本篇只把「清单是四位不是两位」钉住。2.3 它兜不到的东西比兜得到的更值得记default-src只是 fetch 指令的兜底。规范的措辞很干脆frame-ancestors、base-uri、form-action、sandbox、report-urireport-to这些都不在 fetch 指令的兜底范围内。这五条里最容易误解的是frame-ancestors。有人写default-src none觉得「什么都禁了肯定也没法被嵌了」。实际是外部资源全加载不了但被别的站点用框架嵌进来这件事一点没受影响——「我能加载谁」和「谁能嵌我」是两个方向。还有一处更细的例外prefetch、preconnect 这类资源提示请求不归任何单一条 fetch 指令管而是「governed by the union of servers allowed in all of a policy’s directives’ source lists」——由这条策略里所有指令源列表允许的服务器的并集来管。后面还跟了一句更要紧的没写default-src时这类请求「will always be allowed」。所以只写了img-src的策略对 prefetch 完全不管。CSP 逐条生效没写到的地方就是没写到。本章可以带走的一句default-src只填空缺不覆盖已写它管的是 fetch 指令管不到文档、导航和上报也管不住 prefetch 这类资源提示。三、误解二多条策略取「谁更宽」3.1 两条头不是两套方案是两道闸第二个高频误读出在多条策略并存时网关加一条宽的应用加一条严的最后应该以应用那条为准或者后加的覆盖先加的。规范说得明白Enforcing both policies means that a potential connection would have to pass through both unscathed.adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.第一句给判据一个连接要「毫发无伤地穿过两条」。第二句给方向增加策略只能进一步限制不可能放宽。合起来就是一个词——交集。「两个都过」听起来温和后果经常不温和。网关写default-src self应用写default-src self; img-src https://img.example.com后者看起来更宽但交集之后图片域只在应用那条里成立网关仍只认同源图片照样加载不了。要放宽只能改第一条本身或者撤掉它。3.2 脚本那句话最短也最容易被跳过交集这件事规范在脚本这里给了一句最短的话Script will only load if it meets both policy’s criteria.短但藏了一个顺序问题正是本章与第二章的接缝。「两条都要满足」满足的是各自展开之后的判据每条策略先用自己的指令填空缺第二章形成完整判据再取交集本章。顺序决定排查的第一步动作不能跨策略借用。A 策略写了script-src、B 策略没写但有default-src那么 B 对脚本的判据来自它自己的default-src不来自 A 的script-src。报告若不指明触发的是哪条策略就得把每条单独展开一遍。3.3 两个后果都不轻白屏来得莫名其妙。两条头分开看都没问题合起来不允许这时单改任何一条都改不动。判断方法很简单临时去掉其中一条看页面是否恢复。你看到的头可能不是用户拿到的头。规范有一句容易被忽略同一资源的不同表示可以带不同的策略——「A server MAY send different Content-Security-Policy header field values with different representations of the same resource」。落地后果是多机房、灰度、缓存变体都可能让同一个 URL 带不同的头。本章可以带走的一句多条策略是取交集只有收紧一条路把「再加一条宽一点的」当成补丁方向一开始就反了。四、误解三把 Report-Only 当成「先开着看看会不会拦」4.1 它在判定里是被跳过的不是被降级的这个误读最容易出在灰度上线先用 Report-Only 发出去观察没问题再切成强制。流程对错的是理解——很多人以为它是「软性拦截」拦还是会拦只是不显示、只上报。规范在判定算法里给了一句很硬的话If policy’s disposition is “report”, then skip to the next policy.skip to the next policy——跳过看下一条。这句在判定循环内部也就是说disposition为report的策略在「要不要拦这个请求」这个判断里根本没被问过。不是「问了但答案被忽略」是「没问」。由此带出一个直接连着第三章的推论一条 Report-Only 策略不参与交集。它在取交集之前就被跳过了既不放宽也不收紧。写一条比 enforce 更严的页面行为不会有任何变化写一条更宽的也一样。拿「加了 Report-Only 页面还是白的」说明「两条策略取了交集」是把两件事搞混白屏一定来自 enforce 那条。4.2 它能回答什么不能回答什么能回答的这条策略的语法能不能被接受如果切成强制哪些请求会被挡上报通道通不通。不能回答的挡下来之后业务还能不能跑。这是它最大的盲区。一个被挡的请求在 Report-Only 阶段是「一条报告」在 enforce 阶段是「一个功能坏了」——隔的不是程度是性质。「报告里没有关键请求」推不出「切成强制没问题」风险恰恰常在「被拦了但没人知道那是个关键请求」这一侧报告数量本身也受采样与去重影响不能当风险分数用。4.3 从「只报」到「真拦」四步的顺序不能乱对比项Content-Security-PolicyContent-Security-Policy-Report-Only处置dispositionenforcereport是否参与拦截判定参与不参与判定时被跳过是否阻断请求会阻断不阻断是否与其他策略取交集会不会能否写在meta里能不能主要用途执行策略观察这条策略会拦什么第一步先只报内容与将来 enforce 的那条逐字相同。差一个字观察结果就不作数。常见错误是「Report-Only 里先不写那么严」观察到的就不是将来要上线的策略。第二步收集一段时间把「会拦」的请求按指令归类。单位是指令不是 URL因为改法跟着指令走img-src改图床connect-src改接口域名script-src-attr得改代码。第三步拿归类结果去改业务而不是回头改策略。报告一出来就想着把域名补进策略当然能消掉报告但抹掉的是观察结果不是问题。第四步切成 enforce上报通道保留。保留上报不是可选项enforce 之后仍会有新页面带来新违规没有上报只能等用户反馈。本章可以带走的一句Report-Only 是「不拦、只记」它在判定里被直接跳过连交集都不参与把它当成「软性拦截」是最常见的一处误读。五、误解四none并列、空指令、重定向路径5.1none不是加锁是表示「列表为空」第四个误读藏在写法层面策略看着更严了实际更松了。The ‘none’ keyword has no effect when other source expressions are present. That is, the list « ‘none’ » does not match any URL. A list consisting of « ‘none’, https://example.com », on the other hand, would match https://example.com/.拆成两句读。第一句说none和其他源表达式同时存在时没有效果。第二句给对照« none »匹配不了任何 URL而« none, https://example.com »会匹配https://example.com/。源列表内部是「或」的关系任一项匹配即匹配。none永远匹配不上是恒假项恒假项和别的项做「或」结果等于别的项——它被吸收了。这不是「加了一道锁」是「写了一个不生效的项」。有人为了保险把none和允许的域并列期待「既允许这个域又禁止别的」实际是「只允许这个域none那句白写」。结果一样但理解错了下一步会出问题他可能又往里加一个域以为none会拦住它。写法源列表里实际有什么结果script-src none只有none一项任何 URL 都不匹配全部拦下script-src none https://example.comnone加一个主机源等价于只写了example.comscript-src空等价于none任何 URL 都不匹配script-src self一个关键字源同源可加载第三行是下一节的主角。5.2 空指令是最像「没写」的「全禁」An empty source list (that is, a directive without a value: script-src, as opposed to script-src host1) is equivalent to a source list containing ‘none’, and will not match any URL.没有值的指令等价于源列表里只有none。注意方向空不等于「没写」空等于「全禁」。这个语义危险是因为它在配置文件里长得太像「没配」Content-Security-Policy: script-src self https://cdn.example.com Content-Security-Policy: script-src none https://cdn.example.com Content-Security-Policy: script-src⚠️代码待验证第一种正常。第二种里none白写等价于第一种去掉self。第三种最要命语法合法、语义全禁而扫一眼都像「这一行什么都没写」。工程上它几乎总是从模板变量来的。script-src {{ .ScriptSources }}在变量有值时正常为空时渲染出script-src语法合法、语义全禁、页面白屏而模板文件里看不出异常。排查这类问题第一件事是把渲染后的头发出来看而不是读模板。还有一种反向误解以为「写了指令名就算设了一条规则」。按上面那句原文它设的是一条全禁规则。指令名的存在只说明这一格被填了填进去的是空。5.3 重定向之后路径那一段不再参与判定the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect配套例子是img-src example.com example.org/path。读法是源表达式可以带路径主机部分一直有效路径部分只在直接命中时有效一旦这次加载是重定向的结果路径部分就被忽略。这是判定规则不是技巧本文只讲读法。实际影响很具体写https://static.example.com/assets/想表达「只允许这个目录」它在重定向场景下退化成「允许static.example.com整个主机」。你以为限定到了一个目录实际是一个主机。由此有一条纪律不要用源表达式里的路径来表达安全边界。路径只能表达直接请求时的前缀真要限制到目录那是服务端的事。完整版对照资料这份资料把 CSP3 工作草案里 fetch 指令、文档指令、上报指令的归属逐条列成一张对照表和本章「哪条指令归谁管、哪条有兜底」是同一套骨架可以直接拿去核自己站点的那几条头。放在资料包里扫码即可获取本章可以带走的一句none只在列表为空时有意义空列表等于none源表达式里的路径是最不可靠的那一段重定向一发生它就不作数了。六、部署位置和头之间的关系也会改结论6.1meta装不下三样东西也装不下 Report-Only前五章讲「策略里写了什么」这一章讲「写在哪里」——位置本身带限制。The Content-Security-Policy-Report-Only header is not supported inside a meta element. Neither are the report-uri, frame-ancestors, and sandbox directives.一句话里四个「不行」Report-Only 整个不支持report-uri、frame-ancestors、sandbox三个指令不支持。共同点是meta是文档自己说的话而有些判断必须在文档说话之前完成。frame-ancestors最典型。它判的是「这个文档能不能被某个祖先嵌进来」这个判断发生在解析之前——浏览器得先决定要不要把它放进那个框。而meta是解析到那一行才被读到的那时框已经建好了。所以它写在meta里不是「不推荐」是「读不到」。能力响应头meta元素Report-Only 策略支持不支持report-uri支持不支持frame-ancestors支持不支持sandbox支持不支持report-to支持不在上述限制的列举范围内本文不进一步推断解析后修改是否生效不适用响应到达时已固定不生效生效时机响应到达即生效元素被解析时生效越靠前越好倒数第三行是有意留白那句限制只点了三个指令加一个头类型没把report-to列进去但「没列进禁止名单」和「确定可用」是两件事。6.2meta的时机、重复指令、大小写Modifications to the content attribute of a meta element after the element has been parsed will be ignored.元素解析完成后再改content属性改动被忽略。规范顺带建议meta尽量靠前写。这条对应一类很隐蔽的问题有人在脚本里按环境动态改content本地看着生效改动发生在解析之前上线后不生效两边代码一模一样。判断方法只有一个看最终解析出来的那份策略不看 DOM 里现在的content值。指令名大小写不敏感。原话「script-SRC ‘none’ and ScRiPt-sRc ‘none’ are equivalent」。按大小写精确匹配script-src搜配置或日志会漏掉写成Script-Src的那些。同一条策略里重复的指令只取第一个其余忽略。规范有一个 Note 建议浏览器在这种情况下给控制台警告但那只是建议。Content-Security-Policy: script-src self; img-src self; script-src https://cdn.example.com⚠️代码待验证这里script-src出现两次。第二条不合并、不覆盖它被整条忽略。效果是「脚本只认同源」那个 CDN 域等于没写。所以排查时要按出现顺序数而不是找到一个匹配项就停。6.3 同一个响应里两个头谁说了算最后说一处「头与头之间」的关系理解错了会做出「多加一个更保险」这种反向操作。the frame-ancestors directive overrides the X-Frame-Options header覆盖。只要有 enforce 状态的frame-ancestors出现在响应里X-Frame-Options就被忽略。不是「两个都生效取交集」是「前者作数后者不作数」。两者是粗略换算none大致相当于DENYself大致相当于SAMEORIGIN。所以「两个都加更保险」在这里明确是错的frame-ancestors写宽了那个更严的X-Frame-Options不会来兜底。你以为加了两道锁实际是把严的那道换成了宽的。最后补一句report-uri的结论它已被report-to取代原话是「The report-uri directive is deprecated in favor of the new report-to directive, which relies on [REPORTING] as infrastructure」。这也属于替代关系——新的生效旧的按废弃处理不会叠加。本章可以带走的一句部署位置决定哪些指令能被读到头与头之间是覆盖不是叠加「多加一个更保险」在 CSP 里经常恰好相反。七、一份可执行的自查顺序7.1 七步按顺序走前面六章拆了四个误读落到操作上需要顺序后面的结论依赖前面的结果不先数清有几条策略就谈不上「哪条在拦」。第 1 步 数清有几条策略响应头里几条 Content-Security-Policy页面里几个 meta 第 2 步 每条策略单独展开把写了的 fetch 指令标出来剩下的才归 default-src 第 3 步 每条策略单独看 none有没有和别的源并列有没有空值指令 第 4 步 分清哪条是 enforce、哪条是 Report-Only后者不计入交集 第 5 步 确认部署位置写在头里还是 meta 里用到的指令 meta 收不收 第 6 步 按出现顺序数重复指令同一条策略里第一条生效后面的忽略 第 7 步 最后再看上报报告里 effective-directive 落在哪一条决定改法⚠️代码待验证七步里有三个「先别看」的位置。第 2 步之前别看页面表现。白屏和「哪条策略在拦」之间隔着好几层可能是交集可能是空指令可能是default-src被替换掉了。第 5 步之前别改策略。策略写在meta里而你改的是frame-ancestors改一百次也不会生效。第 7 步之前别信报告。报告只说哪个请求被拦了不说「这条策略是不是你要的那条」。被忽略的重复指令不产生报告Report-Only 的报告看起来和 enforce 的一样。7.2 四条误读并到一张表里被读错的点规范里的实际语义自查时先做什么default-src是总开关无继承写了script-src之后default-src对脚本零影响第 2 步标出每条策略里已写的 fetch 指令多条策略取更宽的那条取交集增加策略只能收紧第 1 步数清策略条数别只抓一次头Report-Only 是软性拦截disposition为 report 时在判定里被跳过不参与交集第 4 步先分清哪条在拦none是一种更严的写法与其他源并列时无效果空源列表等价于none第 3 步逐条看源列表是否真的为空概括成一句四条误读共用一个形状——把「没生效的部分」当成了「生效的部分」。default-src在写了具体指令后不生效none在并列时不生效Report-Only 在拦截上不生效重复的第二条指令不生效。你以为它在管其实它没被问到。7.3 这套规则以后会变吗会。这是这一节唯一想强调的。本文所有原文都来自 CSP3 的 2026-09-16 工作草案。它是 Working Draft不是 Recommendation开头说过结尾再说一次因为它决定这份笔记的保质期草案条文会改改的时候不发通知。可迁移的不是这些句子是读的方法——先确认版本再确认这段说的是哪个阶段解析、判定、上报最后确认它管哪一类请求。规范对开发者还有一句明确建议可以直接照做developers SHOULD NOT include either ‘unsafe-inline’, or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself措辞是 SHOULD NOT建议而非禁止但它给的是一个很硬的性质判断这两个源会把「代码能不能进到文档」这道门整个打开。至于它们在有其他放行机制时如何被处理本文不写——本批没核到可直接引用的原文写出来就是替规范说话。strict-dynamic按规范 §8.2 的描述是一种针对 non-parser-inserted 脚本元素的放行机制。这句只作概念说明它改变的是「脚本怎么进来的」这个判据不是「哪个域被允许」具体行为与组合效果需要单独一篇。本章可以带走的一句CSP 的四条误读共用一个形状——把没被问到的部分当成了在管的部分规则本身会随草案版本变只有「先确认版本、再确认阶段、再确认请求类型」这个读法不会变。完整版对照资料这份资料把本文七章用到的那几条判定规则做成了单页检查表从「数清几条策略」到「报告里的 effective-directive 对应哪条改法」和第七章的七步顺序一一对应。放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表序号事实出处核验日期本文位置1CSP3 文档身份W3C Working Draft2026-09-16是工作草案不是 RecommendationW3C CSP3CSP-012026-10-25一 1.1、七 7.32default-src self的等价形式共 12 项脚本与样式拆为-elem与-attr四条无单独的script-srcstyle-srcW3C CSP3CSP-022026-10-25二 2.23「There is no inheritance…the value of default-src has no influence on script requests.」W3C CSP3CSP-02b2026-10-25二 2.1、三 3.14default-src只是 fetch 指令的兜底不是全局开关W3C CSP3CSP-032026-10-25一 1.2、二 2.35prefetchpreconnect 由所有指令源列表的并集管辖未写default-src时「will always be allowed」W3C CSP3CSP-03b2026-10-25二 2.36多条策略取交集「pass through both unscathed」增加策略「can only further restrict」W3C CSP3CSP-042026-10-25三 3.17「Script will only load if it meets both policy’s criteria」W3C CSP3CSP-052026-10-25三 3.28disposition为 report 的策略在判定中被跳过「then skip to the next policy」W3C CSP3CSP-062026-10-25四 4.19none与其他源并列时无效果« none, https://example.com »会匹配该域W3C CSP3CSP-072026-10-25五 5.110空源列表等价于none不匹配任何 URLW3C CSP3CSP-082026-10-25五 5.211加载结果是重定向时匹配算法忽略源表达式里的路径部分W3C CSP3CSP-092026-10-25五 5.312指令名大小写不敏感同一策略内重复指令只取第一个W3C CSP3CSP-102026-10-25六 6.2、七 7.113frame-ancestors覆盖X-Frame-Optionsnone约等于DENYself约等于SAMEORIGINW3C CSP3CSP-112026-10-25六 6.314meta不支持 Report-Only也不支持report-uri、frame-ancestors、sandboxW3C CSP3CSP-122026-10-25六 6.1、四 4.315meta解析后再改content不生效规范建议meta尽量靠前W3C CSP3CSP-132026-10-25六 6.216report-uri已被report-to取代W3C CSP3CSP-142026-10-25四 4.3、六 6.317开发者 SHOULD NOT 把unsafe-inline或data:作为有效源W3C CSP3CSP-152026-10-25七 7.318同一资源的不同表示可以带不同的策略头值W3C CSP3CSP-162026-10-25三 3.319待验证禁止unsafe-inline与 nonce 的交互结论本批未在规范中检到可引用原句全文不写本批纪律CSP-172026-10-25七 7.320禁止本文不写任何绕过类做法与具体白名单技巧strict-dynamic仅作概念说明本批纪律CSP-182026-10-25七 7.321default-src none不覆盖frame-ancestors、base-uri、form-action、sandbox、上报指令W3C CSP3CSP-032026-10-25二 2.32212 项等价清单中每一项各自管辖的请求类型W3C CSP3CSP-022026-10-25二 2.2附表 B术语速查表术语一句话解释fetch 指令管某类请求能不能发出去的指令只有这一类有default-src兜底文档指令管文档自身行为的指令如base-uri、sandbox无兜底导航指令管「谁能嵌我、我能往哪提交」的指令如frame-ancestors、form-action无兜底上报指令管违规信息往哪送的指令如report-uri、report-to无兜底无继承写了具体指令default-src对那一类请求零影响不是优先级低是不参与源列表一条指令后面的那些值内部是「或」的关系任一项匹配即放行none表示「列表为空」的关键字任何 URL 都不匹配与其他源并列时被吸收空源列表只写指令名、不写值语义等价于none即全禁enforcedisposition为 enforce 的策略参与拦截判定与其他 enforce 策略取交集Report-Only只上报不阻断的策略判定时被跳过不参与交集也不能写进metascript-src-elemscript-src-attr脚本元素与内联脚本属性两条分开的判据覆盖frame-ancestors存在时X-Frame-Options被忽略不是叠加是后者不作数写在最后这篇用到的资料写这篇文章时我把 CSP3 工作草案里跟default-src、none、Report-Only 有关的段落来回读了几遍最费劲的是「多条策略取交集」和「Report-Only 不参与交集」要同时成立顺手也整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份再回到自己站点的那几个响应头上按第七章的七步顺序数一遍究竟有几条策略在同时生效。 加了 CSP 还是没拦住：四条被读错的指令语义
授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、先分清 CSP 管的是「加载」还是「执行」1.1 两行一模一样的头两个不一样的结果先说一个具体的场面。有人在自建靶场里给站点加 CSP加得很朴素nginx 里多写一行add_header。加完打开两个页面A 页面图表区整块白了B 页面同一个模板图表正常。他把两边的响应头抓下来逐字比对那一行完全相同。头一样结果不一样于是他判断是浏览器实现有差异。这个判断是错的而错的地方不在浏览器。差别在 B 页面的模板里——那是一份旧模板里面还留着一条script-src。因为这条script-src存在A 页面那行default-src在 B 页面对脚本请求的判定里根本没有参与。它不是总开关只填空缺同一条头给出两种结果不是浏览器不一致是两条策略里「空缺」的位置不同。出处先说清本文引用 W3C《Content Security Policy Level 3》。截至 2026-10-25它的状态是W3C Working Draft日期 2026-09-16地址https://www.w3.org/TR/CSP3/。它是工作草案不是 Recommendation条文还会改所以本文每处原文只对 2026-09-16 这一版负责。1.2 一条策略里混着四种东西很多人把 CSP 当成一份资源白名单。这个印象在早期版本勉强够用放到 Level 3 就不够了一条策略里的指令按作用对象至少分成四类。类别管的问题本文涉及的指令有default-src兜底吗fetch 指令某一类请求能不能发出去script-src-elem、script-src-attr、img-src、connect-src、font-src、object-src有文档指令文档自身的某些行为受不受限base-uri、sandbox没有导航指令谁能嵌我、我能往哪里提交frame-ancestors、form-action没有上报指令违规信息往哪里送report-uri、report-to没有最右一列是全文的骨架只有第一类有兜底后三类没有。default-src的覆盖范围比多数人以为的窄得多——它只管「请求发不发得出去」不管「这份文档能不能被嵌」。分类不是按危险程度分的是按判定发生在哪一刻分的fetch 指令在请求发起前判定手里有一个目标 URL 可比对导航指令没有这个 URLframe-ancestors判的是「能不能被某个祖先嵌进去」也就无从兜底。1.3 「我加了 CSP」这句话本身没有信息量要判断一条 CSP 在做什么至少问清三件事。加在哪里。响应头还是meta元素——meta装不下某些指令第六章。加了几条。一个响应可以有多条策略头多条之间不是「后一条覆盖前一条」第三章。每条里写了哪些指令。写了哪几条 fetch 指令剩下的才轮到default-srcnone那处的列表是否真为空Report-Only 那条是否根本没在拦第二、五、四章。少问一个结论就可能反过来。本章可以带走的一句CSP 不是一份资源白名单而是按请求类型分开判的一组规则说「我加了 CSP」信息量等于零。二、误解一把default-src当成总开关2.1 「no inheritance」这五个字要读三遍规范讲这件事只用了一句话位置很不起眼但它是否掉后面一半误读的钥匙There is no inheritance. If a script-src directive is explicitly specified, for example, then the value of default-src has no influence on script requests.两个词要抓住。no inheritance这里没有继承。has no influence不是影响变小不是优先级更低是没有任何影响。我们平时说「默认值」模型是继承子级没写用父级写了用自己父级还在那儿放着。CSP 不是这个模型它是填表没填的格子default-src帮你填上填过的它连看都不看。Content-Security-Policy: default-src self; script-src https://cdn.example.com⚠️代码待验证这条策略有两处容易读错。第一script-src这一格被填过了default-src从此不参与脚本判定。脚本的放行范围只有「https://cdn.example.com」self不在里面——它不允许加载同源脚本。写它的人想的是「同源照旧再加一个 CDN」按规范语义做的是「把脚本源换成 CDN 一个域」。第二default-src剩下的权力还在图片、字体、样式、连接、媒体、对象没被单独填仍由它兜着。所以在本条策略内部再写一条script-src是替换不是叠加。这和「多写一条更保险」的直觉正好相反。2.2 规范给的等价写法里没有script-srcdefault-src self等价于什么规范直接给了展开式值得原样抄一遍Content-Security-Policy: connect-src self; font-src self; frame-src self; img-src self; manifest-src self; media-src self; object-src self; script-src-elem self; script-src-attr self; style-src-elem self; style-src-attr self; worker-src self⚠️代码待验证一共 12 项序号等价清单里的指令它管的是哪一类请求1connect-src脚本发起的连接XHR、WebSocket 这一类2font-src字体文件3frame-src这一页里嵌进去的子框架4img-src图片5manifest-srcWeb App Manifest6media-src音频与视频7object-src插件类对象8script-src-elem脚本元素9script-src-attr元素上的内联脚本属性10style-src-elem样式元素11style-src-attr元素上的内联样式属性12worker-srcWorker 类脚本有一个必须原样保留、不能「顺手改对」的细节清单里是script-src-elem和script-src-attr不是script-src是style-src-elem和style-src-attr不是style-src。因为在这套判据里「脚本」本来就不是一个东西是两个脚本元素和内联脚本属性走两条判定路径各有各的指令。script-src不在清单里是因为它在这套结构里统管这两者不是被统管的一项——把它展开进清单会把两层压成一层。实际影响有两处。想单独管住内联脚本属性有专门的指令可用不必动整体。排查时看报告里的effective-directive写script-src-attr说明问题出在属性上写script-src-elem才是脚本元素改法完全不同。script-src与这两条如何回落需要另开一篇本篇只把「清单是四位不是两位」钉住。2.3 它兜不到的东西比兜得到的更值得记default-src只是 fetch 指令的兜底。规范的措辞很干脆frame-ancestors、base-uri、form-action、sandbox、report-urireport-to这些都不在 fetch 指令的兜底范围内。这五条里最容易误解的是frame-ancestors。有人写default-src none觉得「什么都禁了肯定也没法被嵌了」。实际是外部资源全加载不了但被别的站点用框架嵌进来这件事一点没受影响——「我能加载谁」和「谁能嵌我」是两个方向。还有一处更细的例外prefetch、preconnect 这类资源提示请求不归任何单一条 fetch 指令管而是「governed by the union of servers allowed in all of a policy’s directives’ source lists」——由这条策略里所有指令源列表允许的服务器的并集来管。后面还跟了一句更要紧的没写default-src时这类请求「will always be allowed」。所以只写了img-src的策略对 prefetch 完全不管。CSP 逐条生效没写到的地方就是没写到。本章可以带走的一句default-src只填空缺不覆盖已写它管的是 fetch 指令管不到文档、导航和上报也管不住 prefetch 这类资源提示。三、误解二多条策略取「谁更宽」3.1 两条头不是两套方案是两道闸第二个高频误读出在多条策略并存时网关加一条宽的应用加一条严的最后应该以应用那条为准或者后加的覆盖先加的。规范说得明白Enforcing both policies means that a potential connection would have to pass through both unscathed.adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.第一句给判据一个连接要「毫发无伤地穿过两条」。第二句给方向增加策略只能进一步限制不可能放宽。合起来就是一个词——交集。「两个都过」听起来温和后果经常不温和。网关写default-src self应用写default-src self; img-src https://img.example.com后者看起来更宽但交集之后图片域只在应用那条里成立网关仍只认同源图片照样加载不了。要放宽只能改第一条本身或者撤掉它。3.2 脚本那句话最短也最容易被跳过交集这件事规范在脚本这里给了一句最短的话Script will only load if it meets both policy’s criteria.短但藏了一个顺序问题正是本章与第二章的接缝。「两条都要满足」满足的是各自展开之后的判据每条策略先用自己的指令填空缺第二章形成完整判据再取交集本章。顺序决定排查的第一步动作不能跨策略借用。A 策略写了script-src、B 策略没写但有default-src那么 B 对脚本的判据来自它自己的default-src不来自 A 的script-src。报告若不指明触发的是哪条策略就得把每条单独展开一遍。3.3 两个后果都不轻白屏来得莫名其妙。两条头分开看都没问题合起来不允许这时单改任何一条都改不动。判断方法很简单临时去掉其中一条看页面是否恢复。你看到的头可能不是用户拿到的头。规范有一句容易被忽略同一资源的不同表示可以带不同的策略——「A server MAY send different Content-Security-Policy header field values with different representations of the same resource」。落地后果是多机房、灰度、缓存变体都可能让同一个 URL 带不同的头。本章可以带走的一句多条策略是取交集只有收紧一条路把「再加一条宽一点的」当成补丁方向一开始就反了。四、误解三把 Report-Only 当成「先开着看看会不会拦」4.1 它在判定里是被跳过的不是被降级的这个误读最容易出在灰度上线先用 Report-Only 发出去观察没问题再切成强制。流程对错的是理解——很多人以为它是「软性拦截」拦还是会拦只是不显示、只上报。规范在判定算法里给了一句很硬的话If policy’s disposition is “report”, then skip to the next policy.skip to the next policy——跳过看下一条。这句在判定循环内部也就是说disposition为report的策略在「要不要拦这个请求」这个判断里根本没被问过。不是「问了但答案被忽略」是「没问」。由此带出一个直接连着第三章的推论一条 Report-Only 策略不参与交集。它在取交集之前就被跳过了既不放宽也不收紧。写一条比 enforce 更严的页面行为不会有任何变化写一条更宽的也一样。拿「加了 Report-Only 页面还是白的」说明「两条策略取了交集」是把两件事搞混白屏一定来自 enforce 那条。4.2 它能回答什么不能回答什么能回答的这条策略的语法能不能被接受如果切成强制哪些请求会被挡上报通道通不通。不能回答的挡下来之后业务还能不能跑。这是它最大的盲区。一个被挡的请求在 Report-Only 阶段是「一条报告」在 enforce 阶段是「一个功能坏了」——隔的不是程度是性质。「报告里没有关键请求」推不出「切成强制没问题」风险恰恰常在「被拦了但没人知道那是个关键请求」这一侧报告数量本身也受采样与去重影响不能当风险分数用。4.3 从「只报」到「真拦」四步的顺序不能乱对比项Content-Security-PolicyContent-Security-Policy-Report-Only处置dispositionenforcereport是否参与拦截判定参与不参与判定时被跳过是否阻断请求会阻断不阻断是否与其他策略取交集会不会能否写在meta里能不能主要用途执行策略观察这条策略会拦什么第一步先只报内容与将来 enforce 的那条逐字相同。差一个字观察结果就不作数。常见错误是「Report-Only 里先不写那么严」观察到的就不是将来要上线的策略。第二步收集一段时间把「会拦」的请求按指令归类。单位是指令不是 URL因为改法跟着指令走img-src改图床connect-src改接口域名script-src-attr得改代码。第三步拿归类结果去改业务而不是回头改策略。报告一出来就想着把域名补进策略当然能消掉报告但抹掉的是观察结果不是问题。第四步切成 enforce上报通道保留。保留上报不是可选项enforce 之后仍会有新页面带来新违规没有上报只能等用户反馈。本章可以带走的一句Report-Only 是「不拦、只记」它在判定里被直接跳过连交集都不参与把它当成「软性拦截」是最常见的一处误读。五、误解四none并列、空指令、重定向路径5.1none不是加锁是表示「列表为空」第四个误读藏在写法层面策略看着更严了实际更松了。The ‘none’ keyword has no effect when other source expressions are present. That is, the list « ‘none’ » does not match any URL. A list consisting of « ‘none’, https://example.com », on the other hand, would match https://example.com/.拆成两句读。第一句说none和其他源表达式同时存在时没有效果。第二句给对照« none »匹配不了任何 URL而« none, https://example.com »会匹配https://example.com/。源列表内部是「或」的关系任一项匹配即匹配。none永远匹配不上是恒假项恒假项和别的项做「或」结果等于别的项——它被吸收了。这不是「加了一道锁」是「写了一个不生效的项」。有人为了保险把none和允许的域并列期待「既允许这个域又禁止别的」实际是「只允许这个域none那句白写」。结果一样但理解错了下一步会出问题他可能又往里加一个域以为none会拦住它。写法源列表里实际有什么结果script-src none只有none一项任何 URL 都不匹配全部拦下script-src none https://example.comnone加一个主机源等价于只写了example.comscript-src空等价于none任何 URL 都不匹配script-src self一个关键字源同源可加载第三行是下一节的主角。5.2 空指令是最像「没写」的「全禁」An empty source list (that is, a directive without a value: script-src, as opposed to script-src host1) is equivalent to a source list containing ‘none’, and will not match any URL.没有值的指令等价于源列表里只有none。注意方向空不等于「没写」空等于「全禁」。这个语义危险是因为它在配置文件里长得太像「没配」Content-Security-Policy: script-src self https://cdn.example.com Content-Security-Policy: script-src none https://cdn.example.com Content-Security-Policy: script-src⚠️代码待验证第一种正常。第二种里none白写等价于第一种去掉self。第三种最要命语法合法、语义全禁而扫一眼都像「这一行什么都没写」。工程上它几乎总是从模板变量来的。script-src {{ .ScriptSources }}在变量有值时正常为空时渲染出script-src语法合法、语义全禁、页面白屏而模板文件里看不出异常。排查这类问题第一件事是把渲染后的头发出来看而不是读模板。还有一种反向误解以为「写了指令名就算设了一条规则」。按上面那句原文它设的是一条全禁规则。指令名的存在只说明这一格被填了填进去的是空。5.3 重定向之后路径那一段不再参与判定the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect配套例子是img-src example.com example.org/path。读法是源表达式可以带路径主机部分一直有效路径部分只在直接命中时有效一旦这次加载是重定向的结果路径部分就被忽略。这是判定规则不是技巧本文只讲读法。实际影响很具体写https://static.example.com/assets/想表达「只允许这个目录」它在重定向场景下退化成「允许static.example.com整个主机」。你以为限定到了一个目录实际是一个主机。由此有一条纪律不要用源表达式里的路径来表达安全边界。路径只能表达直接请求时的前缀真要限制到目录那是服务端的事。完整版对照资料这份资料把 CSP3 工作草案里 fetch 指令、文档指令、上报指令的归属逐条列成一张对照表和本章「哪条指令归谁管、哪条有兜底」是同一套骨架可以直接拿去核自己站点的那几条头。放在资料包里扫码即可获取本章可以带走的一句none只在列表为空时有意义空列表等于none源表达式里的路径是最不可靠的那一段重定向一发生它就不作数了。六、部署位置和头之间的关系也会改结论6.1meta装不下三样东西也装不下 Report-Only前五章讲「策略里写了什么」这一章讲「写在哪里」——位置本身带限制。The Content-Security-Policy-Report-Only header is not supported inside a meta element. Neither are the report-uri, frame-ancestors, and sandbox directives.一句话里四个「不行」Report-Only 整个不支持report-uri、frame-ancestors、sandbox三个指令不支持。共同点是meta是文档自己说的话而有些判断必须在文档说话之前完成。frame-ancestors最典型。它判的是「这个文档能不能被某个祖先嵌进来」这个判断发生在解析之前——浏览器得先决定要不要把它放进那个框。而meta是解析到那一行才被读到的那时框已经建好了。所以它写在meta里不是「不推荐」是「读不到」。能力响应头meta元素Report-Only 策略支持不支持report-uri支持不支持frame-ancestors支持不支持sandbox支持不支持report-to支持不在上述限制的列举范围内本文不进一步推断解析后修改是否生效不适用响应到达时已固定不生效生效时机响应到达即生效元素被解析时生效越靠前越好倒数第三行是有意留白那句限制只点了三个指令加一个头类型没把report-to列进去但「没列进禁止名单」和「确定可用」是两件事。6.2meta的时机、重复指令、大小写Modifications to the content attribute of a meta element after the element has been parsed will be ignored.元素解析完成后再改content属性改动被忽略。规范顺带建议meta尽量靠前写。这条对应一类很隐蔽的问题有人在脚本里按环境动态改content本地看着生效改动发生在解析之前上线后不生效两边代码一模一样。判断方法只有一个看最终解析出来的那份策略不看 DOM 里现在的content值。指令名大小写不敏感。原话「script-SRC ‘none’ and ScRiPt-sRc ‘none’ are equivalent」。按大小写精确匹配script-src搜配置或日志会漏掉写成Script-Src的那些。同一条策略里重复的指令只取第一个其余忽略。规范有一个 Note 建议浏览器在这种情况下给控制台警告但那只是建议。Content-Security-Policy: script-src self; img-src self; script-src https://cdn.example.com⚠️代码待验证这里script-src出现两次。第二条不合并、不覆盖它被整条忽略。效果是「脚本只认同源」那个 CDN 域等于没写。所以排查时要按出现顺序数而不是找到一个匹配项就停。6.3 同一个响应里两个头谁说了算最后说一处「头与头之间」的关系理解错了会做出「多加一个更保险」这种反向操作。the frame-ancestors directive overrides the X-Frame-Options header覆盖。只要有 enforce 状态的frame-ancestors出现在响应里X-Frame-Options就被忽略。不是「两个都生效取交集」是「前者作数后者不作数」。两者是粗略换算none大致相当于DENYself大致相当于SAMEORIGIN。所以「两个都加更保险」在这里明确是错的frame-ancestors写宽了那个更严的X-Frame-Options不会来兜底。你以为加了两道锁实际是把严的那道换成了宽的。最后补一句report-uri的结论它已被report-to取代原话是「The report-uri directive is deprecated in favor of the new report-to directive, which relies on [REPORTING] as infrastructure」。这也属于替代关系——新的生效旧的按废弃处理不会叠加。本章可以带走的一句部署位置决定哪些指令能被读到头与头之间是覆盖不是叠加「多加一个更保险」在 CSP 里经常恰好相反。七、一份可执行的自查顺序7.1 七步按顺序走前面六章拆了四个误读落到操作上需要顺序后面的结论依赖前面的结果不先数清有几条策略就谈不上「哪条在拦」。第 1 步 数清有几条策略响应头里几条 Content-Security-Policy页面里几个 meta 第 2 步 每条策略单独展开把写了的 fetch 指令标出来剩下的才归 default-src 第 3 步 每条策略单独看 none有没有和别的源并列有没有空值指令 第 4 步 分清哪条是 enforce、哪条是 Report-Only后者不计入交集 第 5 步 确认部署位置写在头里还是 meta 里用到的指令 meta 收不收 第 6 步 按出现顺序数重复指令同一条策略里第一条生效后面的忽略 第 7 步 最后再看上报报告里 effective-directive 落在哪一条决定改法⚠️代码待验证七步里有三个「先别看」的位置。第 2 步之前别看页面表现。白屏和「哪条策略在拦」之间隔着好几层可能是交集可能是空指令可能是default-src被替换掉了。第 5 步之前别改策略。策略写在meta里而你改的是frame-ancestors改一百次也不会生效。第 7 步之前别信报告。报告只说哪个请求被拦了不说「这条策略是不是你要的那条」。被忽略的重复指令不产生报告Report-Only 的报告看起来和 enforce 的一样。7.2 四条误读并到一张表里被读错的点规范里的实际语义自查时先做什么default-src是总开关无继承写了script-src之后default-src对脚本零影响第 2 步标出每条策略里已写的 fetch 指令多条策略取更宽的那条取交集增加策略只能收紧第 1 步数清策略条数别只抓一次头Report-Only 是软性拦截disposition为 report 时在判定里被跳过不参与交集第 4 步先分清哪条在拦none是一种更严的写法与其他源并列时无效果空源列表等价于none第 3 步逐条看源列表是否真的为空概括成一句四条误读共用一个形状——把「没生效的部分」当成了「生效的部分」。default-src在写了具体指令后不生效none在并列时不生效Report-Only 在拦截上不生效重复的第二条指令不生效。你以为它在管其实它没被问到。7.3 这套规则以后会变吗会。这是这一节唯一想强调的。本文所有原文都来自 CSP3 的 2026-09-16 工作草案。它是 Working Draft不是 Recommendation开头说过结尾再说一次因为它决定这份笔记的保质期草案条文会改改的时候不发通知。可迁移的不是这些句子是读的方法——先确认版本再确认这段说的是哪个阶段解析、判定、上报最后确认它管哪一类请求。规范对开发者还有一句明确建议可以直接照做developers SHOULD NOT include either ‘unsafe-inline’, or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself措辞是 SHOULD NOT建议而非禁止但它给的是一个很硬的性质判断这两个源会把「代码能不能进到文档」这道门整个打开。至于它们在有其他放行机制时如何被处理本文不写——本批没核到可直接引用的原文写出来就是替规范说话。strict-dynamic按规范 §8.2 的描述是一种针对 non-parser-inserted 脚本元素的放行机制。这句只作概念说明它改变的是「脚本怎么进来的」这个判据不是「哪个域被允许」具体行为与组合效果需要单独一篇。本章可以带走的一句CSP 的四条误读共用一个形状——把没被问到的部分当成了在管的部分规则本身会随草案版本变只有「先确认版本、再确认阶段、再确认请求类型」这个读法不会变。完整版对照资料这份资料把本文七章用到的那几条判定规则做成了单页检查表从「数清几条策略」到「报告里的 effective-directive 对应哪条改法」和第七章的七步顺序一一对应。放在资料包里扫码即可获取附表 A本文引用事实与官方出处对照表序号事实出处核验日期本文位置1CSP3 文档身份W3C Working Draft2026-09-16是工作草案不是 RecommendationW3C CSP3CSP-012026-10-25一 1.1、七 7.32default-src self的等价形式共 12 项脚本与样式拆为-elem与-attr四条无单独的script-srcstyle-srcW3C CSP3CSP-022026-10-25二 2.23「There is no inheritance…the value of default-src has no influence on script requests.」W3C CSP3CSP-02b2026-10-25二 2.1、三 3.14default-src只是 fetch 指令的兜底不是全局开关W3C CSP3CSP-032026-10-25一 1.2、二 2.35prefetchpreconnect 由所有指令源列表的并集管辖未写default-src时「will always be allowed」W3C CSP3CSP-03b2026-10-25二 2.36多条策略取交集「pass through both unscathed」增加策略「can only further restrict」W3C CSP3CSP-042026-10-25三 3.17「Script will only load if it meets both policy’s criteria」W3C CSP3CSP-052026-10-25三 3.28disposition为 report 的策略在判定中被跳过「then skip to the next policy」W3C CSP3CSP-062026-10-25四 4.19none与其他源并列时无效果« none, https://example.com »会匹配该域W3C CSP3CSP-072026-10-25五 5.110空源列表等价于none不匹配任何 URLW3C CSP3CSP-082026-10-25五 5.211加载结果是重定向时匹配算法忽略源表达式里的路径部分W3C CSP3CSP-092026-10-25五 5.312指令名大小写不敏感同一策略内重复指令只取第一个W3C CSP3CSP-102026-10-25六 6.2、七 7.113frame-ancestors覆盖X-Frame-Optionsnone约等于DENYself约等于SAMEORIGINW3C CSP3CSP-112026-10-25六 6.314meta不支持 Report-Only也不支持report-uri、frame-ancestors、sandboxW3C CSP3CSP-122026-10-25六 6.1、四 4.315meta解析后再改content不生效规范建议meta尽量靠前W3C CSP3CSP-132026-10-25六 6.216report-uri已被report-to取代W3C CSP3CSP-142026-10-25四 4.3、六 6.317开发者 SHOULD NOT 把unsafe-inline或data:作为有效源W3C CSP3CSP-152026-10-25七 7.318同一资源的不同表示可以带不同的策略头值W3C CSP3CSP-162026-10-25三 3.319待验证禁止unsafe-inline与 nonce 的交互结论本批未在规范中检到可引用原句全文不写本批纪律CSP-172026-10-25七 7.320禁止本文不写任何绕过类做法与具体白名单技巧strict-dynamic仅作概念说明本批纪律CSP-182026-10-25七 7.321default-src none不覆盖frame-ancestors、base-uri、form-action、sandbox、上报指令W3C CSP3CSP-032026-10-25二 2.32212 项等价清单中每一项各自管辖的请求类型W3C CSP3CSP-022026-10-25二 2.2附表 B术语速查表术语一句话解释fetch 指令管某类请求能不能发出去的指令只有这一类有default-src兜底文档指令管文档自身行为的指令如base-uri、sandbox无兜底导航指令管「谁能嵌我、我能往哪提交」的指令如frame-ancestors、form-action无兜底上报指令管违规信息往哪送的指令如report-uri、report-to无兜底无继承写了具体指令default-src对那一类请求零影响不是优先级低是不参与源列表一条指令后面的那些值内部是「或」的关系任一项匹配即放行none表示「列表为空」的关键字任何 URL 都不匹配与其他源并列时被吸收空源列表只写指令名、不写值语义等价于none即全禁enforcedisposition为 enforce 的策略参与拦截判定与其他 enforce 策略取交集Report-Only只上报不阻断的策略判定时被跳过不参与交集也不能写进metascript-src-elemscript-src-attr脚本元素与内联脚本属性两条分开的判据覆盖frame-ancestors存在时X-Frame-Options被忽略不是叠加是后者不作数写在最后这篇用到的资料写这篇文章时我把 CSP3 工作草案里跟default-src、none、Report-Only 有关的段落来回读了几遍最费劲的是「多条策略取交集」和「Report-Only 不参与交集」要同时成立顺手也整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份再回到自己站点的那几个响应头上按第七章的七步顺序数一遍究竟有几条策略在同时生效。