授權(quán)與合規(guī)聲明本文全部操作對(duì)象均為自建隔離靶場本機(jī)容器或隔離虛擬機(jī)涉及安全測試的環(huán)節(jié)必須以取得合法授權(quán)為前提。未經(jīng)授權(quán)的滲透測試違反《中華人民共和國網(wǎng)絡(luò)安全法》與《刑法》相關(guān)條款須承擔(dān)相應(yīng)法律責(zé)任。本文只講環(huán)境配置、版本對(duì)照與靶場隔離不含任何攻擊步驟、利用載荷與繞過手法請(qǐng)勿將文中環(huán)境指向任何非自有系統(tǒng)。一、先分清 CSP 管的是「加載」還是「執(zhí)行」1.1 兩行一模一樣的頭兩個(gè)不一樣的結(jié)果先說一個(gè)具體的場面。有人在自建靶場里給站點(diǎn)加 CSP加得很樸素nginx 里多寫一行add_header。加完打開兩個(gè)頁面A 頁面圖表區(qū)整塊白了B 頁面同一個(gè)模板圖表正常。他把兩邊的響應(yīng)頭抓下來逐字比對(duì)那一行完全相同。頭一樣結(jié)果不一樣于是他判斷是瀏覽器實(shí)現(xiàn)有差異。這個(gè)判斷是錯(cuò)的而錯(cuò)的地方不在瀏覽器。差別在 B 頁面的模板里——那是一份舊模板里面還留著一條script-src。因?yàn)檫@條script-src存在A 頁面那行default-src在 B 頁面對(duì)腳本請(qǐng)求的判定里根本沒有參與。它不是總開關(guān)只填空缺同一條頭給出兩種結(jié)果不是瀏覽器不一致是兩條策略里「空缺」的位置不同。出處先說清本文引用 W3C《Content Security Policy Level 3》。截至 2026-10-25它的狀態(tài)是W3C Working Draft日期 2026-09-16地址https://www.w3.org/TR/CSP3/。它是工作草案不是 Recommendation條文還會(huì)改所以本文每處原文只對(duì) 2026-09-16 這一版負(fù)責(zé)。1.2 一條策略里混著四種東西很多人把 CSP 當(dāng)成一份資源白名單。這個(gè)印象在早期版本勉強(qiáng)夠用放到 Level 3 就不夠了一條策略里的指令按作用對(duì)象至少分成四類。類別管的問題本文涉及的指令有default-src兜底嗎fetch 指令某一類請(qǐng)求能不能發(fā)出去script-src-elem、script-src-attr、img-src、connect-src、font-src、object-src有文檔指令文檔自身的某些行為受不受限base-uri、sandbox沒有導(dǎo)航指令誰能嵌我、我能往哪里提交frame-ancestors、form-action沒有上報(bào)指令違規(guī)信息往哪里送report-uri、report-to沒有最右一列是全文的骨架只有第一類有兜底后三類沒有。default-src的覆蓋范圍比多數(shù)人以為的窄得多——它只管「請(qǐng)求發(fā)不發(fā)得出去」不管「這份文檔能不能被嵌」。分類不是按危險(xiǎn)程度分的是按判定發(fā)生在哪一刻分的fetch 指令在請(qǐng)求發(fā)起前判定手里有一個(gè)目標(biāo) URL 可比對(duì)導(dǎo)航指令沒有這個(gè) URLframe-ancestors判的是「能不能被某個(gè)祖先嵌進(jìn)去」也就無從兜底。1.3 「我加了 CSP」這句話本身沒有信息量要判斷一條 CSP 在做什么至少問清三件事。加在哪里。響應(yīng)頭還是meta元素——meta裝不下某些指令第六章。加了幾條。一個(gè)響應(yīng)可以有多條策略頭多條之間不是「后一條覆蓋前一條」第三章。每條里寫了哪些指令。寫了哪幾條 fetch 指令剩下的才輪到default-srcnone那處的列表是否真為空Report-Only 那條是否根本沒在攔第二、五、四章。少問一個(gè)結(jié)論就可能反過來。本章可以帶走的一句CSP 不是一份資源白名單而是按請(qǐng)求類型分開判的一組規(guī)則說「我加了 CSP」信息量等于零。二、誤解一把default-src當(dāng)成總開關(guān)2.1 「no inheritance」這五個(gè)字要讀三遍規(guī)范講這件事只用了一句話位置很不起眼但它是否掉后面一半誤讀的鑰匙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.兩個(gè)詞要抓住。no inheritance這里沒有繼承。has no influence不是影響變小不是優(yōu)先級(jí)更低是沒有任何影響。我們平時(shí)說「默認(rèn)值」模型是繼承子級(jí)沒寫用父級(jí)寫了用自己父級(jí)還在那兒放著。CSP 不是這個(gè)模型它是填表沒填的格子default-src幫你填上填過的它連看都不看。Content-Security-Policy: default-src self; script-src https://cdn.example.com??代碼待驗(yàn)證這條策略有兩處容易讀錯(cuò)。第一script-src這一格被填過了default-src從此不參與腳本判定。腳本的放行范圍只有「https://cdn.example.com」self不在里面——它不允許加載同源腳本。寫它的人想的是「同源照舊再加一個(gè) CDN」按規(guī)范語義做的是「把腳本源換成 CDN 一個(gè)域」。第二default-src剩下的權(quán)力還在圖片、字體、樣式、連接、媒體、對(duì)象沒被單獨(dú)填仍由它兜著。所以在本條策略內(nèi)部再寫一條script-src是替換不是疊加。這和「多寫一條更保險(xiǎn)」的直覺正好相反。2.2 規(guī)范給的等價(jià)寫法里沒有script-srcdefault-src self等價(jià)于什么規(guī)范直接給了展開式值得原樣抄一遍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??代碼待驗(yàn)證一共 12 項(xiàng)序號(hào)等價(jià)清單里的指令它管的是哪一類請(qǐng)求1connect-src腳本發(fā)起的連接XHR、WebSocket 這一類2font-src字體文件3frame-src這一頁里嵌進(jìn)去的子框架4img-src圖片5manifest-srcWeb App Manifest6media-src音頻與視頻7object-src插件類對(duì)象8script-src-elem腳本元素9script-src-attr元素上的內(nèi)聯(lián)腳本屬性10style-src-elem樣式元素11style-src-attr元素上的內(nèi)聯(lián)樣式屬性12worker-srcWorker 類腳本有一個(gè)必須原樣保留、不能「順手改對(duì)」的細(xì)節(jié)清單里是script-src-elem和script-src-attr不是script-src是style-src-elem和style-src-attr不是style-src。因?yàn)樵谶@套判據(jù)里「腳本」本來就不是一個(gè)東西是兩個(gè)腳本元素和內(nèi)聯(lián)腳本屬性走兩條判定路徑各有各的指令。script-src不在清單里是因?yàn)樗谶@套結(jié)構(gòu)里統(tǒng)管這兩者不是被統(tǒng)管的一項(xiàng)——把它展開進(jìn)清單會(huì)把兩層壓成一層。實(shí)際影響有兩處。想單獨(dú)管住內(nèi)聯(lián)腳本屬性有專門的指令可用不必動(dòng)整體。排查時(shí)看報(bào)告里的effective-directive寫script-src-attr說明問題出在屬性上寫script-src-elem才是腳本元素改法完全不同。script-src與這兩條如何回落需要另開一篇本篇只把「清單是四位不是兩位」釘住。2.3 它兜不到的東西比兜得到的更值得記default-src只是 fetch 指令的兜底。規(guī)范的措辭很干脆frame-ancestors、base-uri、form-action、sandbox、report-urireport-to這些都不在 fetch 指令的兜底范圍內(nèi)。這五條里最容易誤解的是frame-ancestors。有人寫default-src none覺得「什么都禁了肯定也沒法被嵌了」。實(shí)際是外部資源全加載不了但被別的站點(diǎn)用框架嵌進(jìn)來這件事一點(diǎn)沒受影響——「我能加載誰」和「誰能嵌我」是兩個(gè)方向。還有一處更細(xì)的例外prefetch、preconnect 這類資源提示請(qǐng)求不歸任何單一條 fetch 指令管而是「governed by the union of servers allowed in all of a policy’s directives’ source lists」——由這條策略里所有指令源列表允許的服務(wù)器的并集來管。后面還跟了一句更要緊的沒寫default-src時(shí)這類請(qǐng)求「will always be allowed」。所以只寫了img-src的策略對(duì) prefetch 完全不管。CSP 逐條生效沒寫到的地方就是沒寫到。本章可以帶走的一句default-src只填空缺不覆蓋已寫它管的是 fetch 指令管不到文檔、導(dǎo)航和上報(bào)也管不住 prefetch 這類資源提示。三、誤解二多條策略取「誰更寬」3.1 兩條頭不是兩套方案是兩道閘第二個(gè)高頻誤讀出在多條策略并存時(shí)網(wǎng)關(guān)加一條寬的應(yīng)用加一條嚴(yán)的最后應(yīng)該以應(yīng)用那條為準(zhǔn)或者后加的覆蓋先加的。規(guī)范說得明白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.第一句給判據(jù)一個(gè)連接要「毫發(fā)無傷地穿過兩條」。第二句給方向增加策略只能進(jìn)一步限制不可能放寬。合起來就是一個(gè)詞——交集。「兩個(gè)都過」聽起來溫和后果經(jīng)常不溫和。網(wǎng)關(guān)寫default-src self應(yīng)用寫default-src self; img-src https://img.example.com后者看起來更寬但交集之后圖片域只在應(yīng)用那條里成立網(wǎng)關(guān)仍只認(rèn)同源圖片照樣加載不了。要放寬只能改第一條本身或者撤掉它。3.2 腳本那句話最短也最容易被跳過交集這件事規(guī)范在腳本這里給了一句最短的話Script will only load if it meets both policy’s criteria.短但藏了一個(gè)順序問題正是本章與第二章的接縫?！竷蓷l都要滿足」?jié)M足的是各自展開之后的判據(jù)每條策略先用自己的指令填空缺第二章形成完整判據(jù)再取交集本章。順序決定排查的第一步動(dòng)作不能跨策略借用。A 策略寫了script-src、B 策略沒寫但有default-src那么 B 對(duì)腳本的判據(jù)來自它自己的default-src不來自 A 的script-src。報(bào)告若不指明觸發(fā)的是哪條策略就得把每條單獨(dú)展開一遍。3.3 兩個(gè)后果都不輕白屏來得莫名其妙。兩條頭分開看都沒問題合起來不允許這時(shí)單改任何一條都改不動(dòng)。判斷方法很簡單臨時(shí)去掉其中一條看頁面是否恢復(fù)。你看到的頭可能不是用戶拿到的頭。規(guī)范有一句容易被忽略同一資源的不同表示可以帶不同的策略——「A server MAY send different Content-Security-Policy header field values with different representations of the same resource」。落地后果是多機(jī)房、灰度、緩存變體都可能讓同一個(gè) URL 帶不同的頭。本章可以帶走的一句多條策略是取交集只有收緊一條路把「再加一條寬一點(diǎn)的」當(dāng)成補(bǔ)丁方向一開始就反了。四、誤解三把 Report-Only 當(dāng)成「先開著看看會(huì)不會(huì)攔」4.1 它在判定里是被跳過的不是被降級(jí)的這個(gè)誤讀最容易出在灰度上線先用 Report-Only 發(fā)出去觀察沒問題再切成強(qiáng)制。流程對(duì)錯(cuò)的是理解——很多人以為它是「軟性攔截」攔還是會(huì)攔只是不顯示、只上報(bào)。規(guī)范在判定算法里給了一句很硬的話If policy’s disposition is “report”, then skip to the next policy.skip to the next policy——跳過看下一條。這句在判定循環(huán)內(nèi)部也就是說disposition為report的策略在「要不要攔這個(gè)請(qǐng)求」這個(gè)判斷里根本沒被問過。不是「問了但答案被忽略」是「沒問」。由此帶出一個(gè)直接連著第三章的推論一條 Report-Only 策略不參與交集。它在取交集之前就被跳過了既不放寬也不收緊。寫一條比 enforce 更嚴(yán)的頁面行為不會(huì)有任何變化寫一條更寬的也一樣。拿「加了 Report-Only 頁面還是白的」說明「兩條策略取了交集」是把兩件事搞混白屏一定來自 enforce 那條。4.2 它能回答什么不能回答什么能回答的這條策略的語法能不能被接受如果切成強(qiáng)制哪些請(qǐng)求會(huì)被擋上報(bào)通道通不通。不能回答的擋下來之后業(yè)務(wù)還能不能跑。這是它最大的盲區(qū)。一個(gè)被擋的請(qǐng)求在 Report-Only 階段是「一條報(bào)告」在 enforce 階段是「一個(gè)功能壞了」——隔的不是程度是性質(zhì)?！笀?bào)告里沒有關(guān)鍵請(qǐng)求」推不出「切成強(qiáng)制沒問題」風(fēng)險(xiǎn)恰恰常在「被攔了但沒人知道那是個(gè)關(guān)鍵請(qǐng)求」這一側(cè)報(bào)告數(shù)量本身也受采樣與去重影響不能當(dāng)風(fēng)險(xiǎn)分?jǐn)?shù)用。4.3 從「只報(bào)」到「真攔」四步的順序不能亂對(duì)比項(xiàng)Content-Security-PolicyContent-Security-Policy-Report-Only處置dispositionenforcereport是否參與攔截判定參與不參與判定時(shí)被跳過是否阻斷請(qǐng)求會(huì)阻斷不阻斷是否與其他策略取交集會(huì)不會(huì)能否寫在meta里能不能主要用途執(zhí)行策略觀察這條策略會(huì)攔什么第一步先只報(bào)內(nèi)容與將來 enforce 的那條逐字相同。差一個(gè)字觀察結(jié)果就不作數(shù)。常見錯(cuò)誤是「Report-Only 里先不寫那么嚴(yán)」觀察到的就不是將來要上線的策略。第二步收集一段時(shí)間把「會(huì)攔」的請(qǐng)求按指令歸類。單位是指令不是 URL因?yàn)楦姆ǜ噶钭遡mg-src改圖床connect-src改接口域名script-src-attr得改代碼。第三步拿歸類結(jié)果去改業(yè)務(wù)而不是回頭改策略。報(bào)告一出來就想著把域名補(bǔ)進(jìn)策略當(dāng)然能消掉報(bào)告但抹掉的是觀察結(jié)果不是問題。第四步切成 enforce上報(bào)通道保留。保留上報(bào)不是可選項(xiàng)enforce 之后仍會(huì)有新頁面帶來新違規(guī)沒有上報(bào)只能等用戶反饋。本章可以帶走的一句Report-Only 是「不攔、只記」它在判定里被直接跳過連交集都不參與把它當(dāng)成「軟性攔截」是最常見的一處誤讀。五、誤解四none并列、空指令、重定向路徑5.1none不是加鎖是表示「列表為空」第四個(gè)誤讀藏在寫法層面策略看著更嚴(yán)了實(shí)際更松了。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和其他源表達(dá)式同時(shí)存在時(shí)沒有效果。第二句給對(duì)照? none ?匹配不了任何 URL而? none, https://example.com ?會(huì)匹配https://example.com/。源列表內(nèi)部是「或」的關(guān)系任一項(xiàng)匹配即匹配。none永遠(yuǎn)匹配不上是恒假項(xiàng)恒假項(xiàng)和別的項(xiàng)做「或」結(jié)果等于別的項(xiàng)——它被吸收了。這不是「加了一道鎖」是「寫了一個(gè)不生效的項(xiàng)」。有人為了保險(xiǎn)把none和允許的域并列期待「既允許這個(gè)域又禁止別的」實(shí)際是「只允許這個(gè)域none那句白寫」。結(jié)果一樣但理解錯(cuò)了下一步會(huì)出問題他可能又往里加一個(gè)域以為none會(huì)攔住它。寫法源列表里實(shí)際有什么結(jié)果script-src none只有none一項(xiàng)任何 URL 都不匹配全部攔下script-src none https://example.comnone加一個(gè)主機(jī)源等價(jià)于只寫了example.comscript-src空等價(jià)于none任何 URL 都不匹配script-src self一個(gè)關(guān)鍵字源同源可加載第三行是下一節(jié)的主角。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.沒有值的指令等價(jià)于源列表里只有none。注意方向空不等于「沒寫」空等于「全禁」。這個(gè)語義危險(xiǎn)是因?yàn)樗谂渲梦募镩L得太像「沒配」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??代碼待驗(yàn)證第一種正常。第二種里none白寫等價(jià)于第一種去掉self。第三種最要命語法合法、語義全禁而掃一眼都像「這一行什么都沒寫」。工程上它幾乎總是從模板變量來的。script-src {{ .ScriptSources }}在變量有值時(shí)正常為空時(shí)渲染出script-src語法合法、語義全禁、頁面白屏而模板文件里看不出異常。排查這類問題第一件事是把渲染后的頭發(fā)出來看而不是讀模板。還有一種反向誤解以為「寫了指令名就算設(shè)了一條規(guī)則」。按上面那句原文它設(shè)的是一條全禁規(guī)則。指令名的存在只說明這一格被填了填進(jìn)去的是空。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。讀法是源表達(dá)式可以帶路徑主機(jī)部分一直有效路徑部分只在直接命中時(shí)有效一旦這次加載是重定向的結(jié)果路徑部分就被忽略。這是判定規(guī)則不是技巧本文只講讀法。實(shí)際影響很具體寫https://static.example.com/assets/想表達(dá)「只允許這個(gè)目錄」它在重定向場景下退化成「允許static.example.com整個(gè)主機(jī)」。你以為限定到了一個(gè)目錄實(shí)際是一個(gè)主機(jī)。由此有一條紀(jì)律不要用源表達(dá)式里的路徑來表達(dá)安全邊界。路徑只能表達(dá)直接請(qǐng)求時(shí)的前綴真要限制到目錄那是服務(wù)端的事。完整版對(duì)照資料這份資料把 CSP3 工作草案里 fetch 指令、文檔指令、上報(bào)指令的歸屬逐條列成一張對(duì)照表和本章「哪條指令歸誰管、哪條有兜底」是同一套骨架可以直接拿去核自己站點(diǎn)的那幾條頭。放在資料包里掃碼即可獲取本章可以帶走的一句none只在列表為空時(shí)有意義空列表等于none源表達(dá)式里的路徑是最不可靠的那一段重定向一發(fā)生它就不作數(shù)了。六、部署位置和頭之間的關(guān)系也會(huì)改結(jié)論6.1meta裝不下三樣?xùn)|西也裝不下 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.一句話里四個(gè)「不行」Report-Only 整個(gè)不支持report-uri、frame-ancestors、sandbox三個(gè)指令不支持。共同點(diǎn)是meta是文檔自己說的話而有些判斷必須在文檔說話之前完成。frame-ancestors最典型。它判的是「這個(gè)文檔能不能被某個(gè)祖先嵌進(jìn)來」這個(gè)判斷發(fā)生在解析之前——瀏覽器得先決定要不要把它放進(jìn)那個(gè)框。而meta是解析到那一行才被讀到的那時(shí)框已經(jīng)建好了。所以它寫在meta里不是「不推薦」是「讀不到」。能力響應(yīng)頭meta元素Report-Only 策略支持不支持report-uri支持不支持frame-ancestors支持不支持sandbox支持不支持report-to支持不在上述限制的列舉范圍內(nèi)本文不進(jìn)一步推斷解析后修改是否生效不適用響應(yīng)到達(dá)時(shí)已固定不生效生效時(shí)機(jī)響應(yīng)到達(dá)即生效元素被解析時(shí)生效越靠前越好倒數(shù)第三行是有意留白那句限制只點(diǎn)了三個(gè)指令加一個(gè)頭類型沒把report-to列進(jìn)去但「沒列進(jìn)禁止名單」和「確定可用」是兩件事。6.2meta的時(shí)機(jī)、重復(fù)指令、大小寫Modifications to the content attribute of a meta element after the element has been parsed will be ignored.元素解析完成后再改content屬性改動(dòng)被忽略。規(guī)范順帶建議meta盡量靠前寫。這條對(duì)應(yīng)一類很隱蔽的問題有人在腳本里按環(huán)境動(dòng)態(tài)改content本地看著生效改動(dòng)發(fā)生在解析之前上線后不生效兩邊代碼一模一樣。判斷方法只有一個(gè)看最終解析出來的那份策略不看 DOM 里現(xiàn)在的content值。指令名大小寫不敏感。原話「script-SRC ‘none’ and ScRiPt-sRc ‘none’ are equivalent」。按大小寫精確匹配script-src搜配置或日志會(huì)漏掉寫成Script-Src的那些。同一條策略里重復(fù)的指令只取第一個(gè)其余忽略。規(guī)范有一個(gè) Note 建議瀏覽器在這種情況下給控制臺(tái)警告但那只是建議。Content-Security-Policy: script-src self; img-src self; script-src https://cdn.example.com??代碼待驗(yàn)證這里script-src出現(xiàn)兩次。第二條不合并、不覆蓋它被整條忽略。效果是「腳本只認(rèn)同源」那個(gè) CDN 域等于沒寫。所以排查時(shí)要按出現(xiàn)順序數(shù)而不是找到一個(gè)匹配項(xiàng)就停。6.3 同一個(gè)響應(yīng)里兩個(gè)頭誰說了算最后說一處「頭與頭之間」的關(guān)系理解錯(cuò)了會(huì)做出「多加一個(gè)更保險(xiǎn)」這種反向操作。the frame-ancestors directive overrides the X-Frame-Options header覆蓋。只要有 enforce 狀態(tài)的frame-ancestors出現(xiàn)在響應(yīng)里X-Frame-Options就被忽略。不是「兩個(gè)都生效取交集」是「前者作數(shù)后者不作數(shù)」。兩者是粗略換算none大致相當(dāng)于DENYself大致相當(dāng)于SAMEORIGIN。所以「兩個(gè)都加更保險(xiǎn)」在這里明確是錯(cuò)的frame-ancestors寫寬了那個(gè)更嚴(yán)的X-Frame-Options不會(huì)來兜底。你以為加了兩道鎖實(shí)際是把嚴(yán)的那道換成了寬的。最后補(bǔ)一句report-uri的結(jié)論它已被report-to取代原話是「The report-uri directive is deprecated in favor of the new report-to directive, which relies on [REPORTING] as infrastructure」。這也屬于替代關(guān)系——新的生效舊的按廢棄處理不會(huì)疊加。本章可以帶走的一句部署位置決定哪些指令能被讀到頭與頭之間是覆蓋不是疊加「多加一個(gè)更保險(xiǎn)」在 CSP 里經(jīng)常恰好相反。七、一份可執(zhí)行的自查順序7.1 七步按順序走前面六章拆了四個(gè)誤讀落到操作上需要順序后面的結(jié)論依賴前面的結(jié)果不先數(shù)清有幾條策略就談不上「哪條在攔」。第 1 步 數(shù)清有幾條策略響應(yīng)頭里幾條 Content-Security-Policy頁面里幾個(gè) meta 第 2 步 每條策略單獨(dú)展開把寫了的 fetch 指令標(biāo)出來剩下的才歸 default-src 第 3 步 每條策略單獨(dú)看 none有沒有和別的源并列有沒有空值指令 第 4 步 分清哪條是 enforce、哪條是 Report-Only后者不計(jì)入交集 第 5 步 確認(rèn)部署位置寫在頭里還是 meta 里用到的指令 meta 收不收 第 6 步 按出現(xiàn)順序數(shù)重復(fù)指令同一條策略里第一條生效后面的忽略 第 7 步 最后再看上報(bào)報(bào)告里 effective-directive 落在哪一條決定改法??代碼待驗(yàn)證七步里有三個(gè)「先別看」的位置。第 2 步之前別看頁面表現(xiàn)。白屏和「哪條策略在攔」之間隔著好幾層可能是交集可能是空指令可能是default-src被替換掉了。第 5 步之前別改策略。策略寫在meta里而你改的是frame-ancestors改一百次也不會(huì)生效。第 7 步之前別信報(bào)告。報(bào)告只說哪個(gè)請(qǐng)求被攔了不說「這條策略是不是你要的那條」。被忽略的重復(fù)指令不產(chǎn)生報(bào)告Report-Only 的報(bào)告看起來和 enforce 的一樣。7.2 四條誤讀并到一張表里被讀錯(cuò)的點(diǎn)規(guī)范里的實(shí)際語義自查時(shí)先做什么default-src是總開關(guān)無繼承寫了script-src之后default-src對(duì)腳本零影響第 2 步標(biāo)出每條策略里已寫的 fetch 指令多條策略取更寬的那條取交集增加策略只能收緊第 1 步數(shù)清策略條數(shù)別只抓一次頭Report-Only 是軟性攔截disposition為 report 時(shí)在判定里被跳過不參與交集第 4 步先分清哪條在攔none是一種更嚴(yán)的寫法與其他源并列時(shí)無效果空源列表等價(jià)于none第 3 步逐條看源列表是否真的為空概括成一句四條誤讀共用一個(gè)形狀——把「沒生效的部分」當(dāng)成了「生效的部分」。default-src在寫了具體指令后不生效none在并列時(shí)不生效Report-Only 在攔截上不生效重復(fù)的第二條指令不生效。你以為它在管其實(shí)它沒被問到。7.3 這套規(guī)則以后會(huì)變嗎會(huì)。這是這一節(jié)唯一想強(qiáng)調(diào)的。本文所有原文都來自 CSP3 的 2026-09-16 工作草案。它是 Working Draft不是 Recommendation開頭說過結(jié)尾再說一次因?yàn)樗鼪Q定這份筆記的保質(zhì)期草案條文會(huì)改改的時(shí)候不發(fā)通知?？蛇w移的不是這些句子是讀的方法——先確認(rèn)版本再確認(rèn)這段說的是哪個(gè)階段解析、判定、上報(bào)最后確認(rèn)它管哪一類請(qǐng)求。規(guī)范對(duì)開發(fā)者還有一句明確建議可以直接照做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建議而非禁止但它給的是一個(gè)很硬的性質(zhì)判斷這兩個(gè)源會(huì)把「代碼能不能進(jìn)到文檔」這道門整個(gè)打開。至于它們?cè)谟衅渌判袡C(jī)制時(shí)如何被處理本文不寫——本批沒核到可直接引用的原文寫出來就是替規(guī)范說話。strict-dynamic按規(guī)范 §8.2 的描述是一種針對(duì) non-parser-inserted 腳本元素的放行機(jī)制。這句只作概念說明它改變的是「腳本怎么進(jìn)來的」這個(gè)判據(jù)不是「哪個(gè)域被允許」具體行為與組合效果需要單獨(dú)一篇。本章可以帶走的一句CSP 的四條誤讀共用一個(gè)形狀——把沒被問到的部分當(dāng)成了在管的部分規(guī)則本身會(huì)隨草案版本變只有「先確認(rèn)版本、再確認(rèn)階段、再確認(rèn)請(qǐng)求類型」這個(gè)讀法不會(huì)變。完整版對(duì)照資料這份資料把本文七章用到的那幾條判定規(guī)則做成了單頁檢查表從「數(shù)清幾條策略」到「報(bào)告里的 effective-directive 對(duì)應(yīng)哪條改法」和第七章的七步順序一一對(duì)應(yīng)。放在資料包里掃碼即可獲取附表 A本文引用事實(shí)與官方出處對(duì)照表序號(hào)事實(shí)出處核驗(yàn)日期本文位置1CSP3 文檔身份W3C Working Draft2026-09-16是工作草案不是 RecommendationW3C CSP3CSP-012026-10-25一 1.1、七 7.32default-src self的等價(jià)形式共 12 項(xiàng)腳本與樣式拆為-elem與-attr四條無單獨(dú)的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 指令的兜底不是全局開關(guān)W3C CSP3CSP-032026-10-25一 1.2、二 2.35prefetchpreconnect 由所有指令源列表的并集管轄未寫default-src時(shí)「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與其他源并列時(shí)無效果? none, https://example.com ?會(huì)匹配該域W3C CSP3CSP-072026-10-25五 5.110空源列表等價(jià)于none不匹配任何 URLW3C CSP3CSP-082026-10-25五 5.211加載結(jié)果是重定向時(shí)匹配算法忽略源表達(dá)式里的路徑部分W3C CSP3CSP-092026-10-25五 5.312指令名大小寫不敏感同一策略內(nèi)重復(fù)指令只取第一個(gè)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不生效規(guī)范建議meta盡量靠前W3C CSP3CSP-132026-10-25六 6.216report-uri已被report-to取代W3C CSP3CSP-142026-10-25四 4.3、六 6.317開發(fā)者 SHOULD NOT 把unsafe-inline或data:作為有效源W3C CSP3CSP-152026-10-25七 7.318同一資源的不同表示可以帶不同的策略頭值W3C CSP3CSP-162026-10-25三 3.319待驗(yàn)證禁止unsafe-inline與 nonce 的交互結(jié)論本批未在規(guī)范中檢到可引用原句全文不寫本批紀(jì)律CSP-172026-10-25七 7.320禁止本文不寫任何繞過類做法與具體白名單技巧strict-dynamic僅作概念說明本批紀(jì)律CSP-182026-10-25七 7.321default-src none不覆蓋frame-ancestors、base-uri、form-action、sandbox、上報(bào)指令W3C CSP3CSP-032026-10-25二 2.32212 項(xiàng)等價(jià)清單中每一項(xiàng)各自管轄的請(qǐng)求類型W3C CSP3CSP-022026-10-25二 2.2附表 B術(shù)語速查表術(shù)語一句話解釋fetch 指令管某類請(qǐng)求能不能發(fā)出去的指令只有這一類有default-src兜底文檔指令管文檔自身行為的指令如base-uri、sandbox無兜底導(dǎo)航指令管「誰能嵌我、我能往哪提交」的指令如frame-ancestors、form-action無兜底上報(bào)指令管違規(guī)信息往哪送的指令如report-uri、report-to無兜底無繼承寫了具體指令default-src對(duì)那一類請(qǐng)求零影響不是優(yōu)先級(jí)低是不參與源列表一條指令后面的那些值內(nèi)部是「或」的關(guān)系任一項(xiàng)匹配即放行none表示「列表為空」的關(guān)鍵字任何 URL 都不匹配與其他源并列時(shí)被吸收空源列表只寫指令名、不寫值語義等價(jià)于none即全禁enforcedisposition為 enforce 的策略參與攔截判定與其他 enforce 策略取交集Report-Only只上報(bào)不阻斷的策略判定時(shí)被跳過不參與交集也不能寫進(jìn)metascript-src-elemscript-src-attr腳本元素與內(nèi)聯(lián)腳本屬性兩條分開的判據(jù)覆蓋frame-ancestors存在時(shí)X-Frame-Options被忽略不是疊加是后者不作數(shù)寫在最后這篇用到的資料寫這篇文章時(shí)我把 CSP3 工作草案里跟default-src、none、Report-Only 有關(guān)的段落來回讀了幾遍最費(fèi)勁的是「多條策略取交集」和「Report-Only 不參與交集」要同時(shí)成立順手也整理了幾份配套的東西靶場環(huán)境對(duì)照表DVWA、upload-labs 在 Windows / macOS / Linux 三平臺(tái)的可行性與推薦路徑Web 安全學(xué)習(xí)路線圖從基礎(chǔ)打牢到安全管理四個(gè)階段各學(xué)什么常用靶場清單每個(gè)靶場練什么、適合哪個(gè)階段資料是我自己整理的放在下面這個(gè)碼上掃碼即可獲取添加時(shí)備注「靶場」優(yōu)先通過。拿到之后建議先看環(huán)境對(duì)照表那一份再回到自己站點(diǎn)的那幾個(gè)響應(yīng)頭上按第七章的七步順序數(shù)一遍究竟有幾條策略在同時(shí)生效。