HTML5: Misconfigured Content Security Policy

配置不正確的內容安全性原則 (CSP) 會使應用程式面臨用戶端威脅，包括 Cross-site scripting、跨框架指令碼和跨網站偽造要求。

內容安全性原則 (CSP) 是一種宣告式安全性標頭，可讓開發人員指示在網頁瀏覽器中轉譯時，允許網站從哪些網域載入內容或起始到哪些網域的連線。除了程式碼中的輸入驗證和檢查允許清單外，它還提供額外一層的安全性，以防禦重要弱點，例如，Cross-Site Scripting、Clickjacking、Cross-Origin Access 等。但設定不當的標頭無法提供這種額外一層的安全性。該原則藉助於 15 個指令進行定義，其中包括 8 個用於控制資源存取的指令，即：script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src。

每個指令都使用來源清單做為一個值，此值指定針對該指令所涵蓋的功能，網站可存取的網域。開發人員可使用萬用字元 * 來指示所有或部分來源。所有指令都不是強制性的。瀏覽器將允許未列示指令的所有來源，或從選用的 default-src 指令衍生值。此外，此表頭的規格隨著時間的推移而不斷演變。在第 23 版之前的 Firefox 和第 10 版之前的 IE 中，其實做為 X-Content-Security-Policy，而在第 25 版之前的 Chrome 中，其實做為 X-Webkit-CSP。兩個名稱都已棄用，取代為現在的標準名稱 Content Security Policy。鑒於指令的數目、兩個棄用的替代名稱，以及對待多次出現之同一表頭和單一表頭中重複指令的方式，開發人員很可能會錯誤地配置此表頭。

考慮以下配置錯誤的情況：

- 具有 unsafe-inline 或 unsafe-eval 的指令違背了 CSP 的目的。
- 已設定 script-src 指令，但未配置任何 Script nonce。
- 已設定 frame-src，但未配置任何 sandbox。
- 在同一回應中允許使用此表頭的多個實例。開發團隊和安全性團隊可能都會設定表頭，但其中一個可能會使用棄用的名稱之一。雖然在不存在具有最新名稱 (即，內容安全性原則) 的表頭時會接受棄用的表頭，但如果存在具有 content-security-header 名稱的原則，便會忽略棄用的表頭。舊版本只理解棄用的名稱，因此，要實現預期支援，回應必須包含具有這三個名稱的相同原則。
- 如果在表頭的同一實例中重複出現某個指令，則會忽略之後出現的所有該指令。

範例 1：以下 django-csp 配置使用不安全的指令 unsafe-inline 和 unsafe-eval，以便允許內嵌 Script 和程式碼評估：

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...