內容簡介
內容安全策略(Content Security Policy, CSP)是一種計算機安全標準，旨在防止跨站腳本(XSS)、點擊劫持及其他代碼注入攻擊，在信任的網頁上下文中執行惡意內容。
跨站腳本(XSS)是一種存在於某些 Web 應用程式中的安全漏洞。
XSS 攻擊使攻擊者能夠將客戶端腳本注入到其他使用者查看的網頁中。
跨站腳本漏洞可被攻擊者用於繞過訪問控制，如同源策略。
根據由美國 NIST 主持的國家漏洞數據庫(National Vulnerability Database)，報告有超過 1600 個 Xss 微型化字型名稱 Plugins 和主題的漏洞。
保持網站與最新版本的外掛和主題同步是確保網站安全的第一道防線。
第二步要做的是部署嚴格的內容安全策略。
主要問題
實際執行的內容安全策略的主要問題在於它們對保護您的網站來說太弱，並且它們中的許多策略可以輕易地被攻擊者繞過。
提出的解決方案
Google 研究人員建議，除了整個主機白名單之外，藉由 CSP nonce 方法啟用個別腳本。
此外，為了促進 nonce CSP 的採用，他們提出了“strict-dynamic”關鍵字。
WordPress 中 CSP 的問題
手動創建策略
通常，WordPress 項目是由不同作者編寫的程式碼組合而成，他們貢獻於核心，或編寫了插件和主題。
如果可以為包含在 <script src=""> 中的每個外部腳本加入白名單，真正的問題是在 WordPress 項目中可以有幾十個這些腳本，計算出每個腳本的加密哈希值並將其包含在 CSP 標頭中可能會是一個令人沮喪的工作。然而，有許多瀏覽器擴展和 WordPress 的外掛可以幫助您完成此項任務。
內聯腳本
WordPress 核心和外掛使用內聯腳本。對於這些腳本，只有當這些腳本在任何頁面載入時都不會更改時，才可以計算它們的哈希值並手動插入到您的策略中。不幸的是，這不太常見，因為經常在內聯腳本中包含在服務器端計算的變量值。這意味著您的內聯腳本變化太頻繁，以至於無法手動添加它們的哈希值到您的策略。
這通常發生在腳本被“本地化”時。
WordPress 沒有 API 來實現 CSP 的 nonce
即使很容易為每個頁面視圖生成 nonce，但是必須在用於嵌入頁面內聯腳本的每個腳本標籤中插入此 nonce
<script nonce="rAnd0m">
doWhatever();
</script>
以及在 script-src 指令：
script-src 'nonce-rAnd0m';
當然，每個 HTTP 響應都必須是唯一的 nonce。
不安全的哈希 / 內聯樣式表
有時，HTML 元素，如圖像或按鈕，使用 HTML 事件屬性 (onclick、onsubmit…) 來讓事件觸發瀏覽器中的操作。
外掛標籤
開發者團隊
原文外掛簡介
Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.
Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications.
XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.
A cross-site scripting vulnerability may be used by attackers to bypass access controls like the same-origin policy.
Looking at National Vulnerability Database run by US NIST, more than 1100 (November 2025) vulnerabilities are reported as XSS for WordPress’ plugins and themes.
Keeping your site up-to-date with the latest versions of plugins and themes is the first line of defense to ensure your site’s security.
The second thing to do, is to deploy a strict Content Security Policy.
The main problem
The main problem with Content Security Policies implemented in the real world is that they are too weak to really protect your site and that many of them can be trivially bypassed by an attacker.
The proposed solution
Google researchers recommend, instead of whole host whitelisting, to activate individual scripts via a CSP nonces approach.
In addition, in order to facilitate the adoption of nonce-based CSP, they proposed the ’strict-dynamic’ keyword.
The problem(s) with CSP in WordPress
Manual creation of a policy
Usually, a WordPress project is a mix of code written by different authors who contributed to the Core and or wrote plugins and themes.
If it is possible to whitelist every external script loaded from a
and in your script-src directive:
script-src 'nonce-rAnd0m';
And, of course, a nonce must be unique for each HTTP response.
Unsafe hashes / Inline styles
Sometimes, HTML elements as images or buttons use HTML Event Attributes (onclick, onsubmit…) to let events trigger actions in a browser.
You cannot use hashes or nonces for script included in event attributes and, adopting a strict CSP, requires refactoring those patterns into safer alternatives or to use ‘unsafe-hashes’.
You got a similar problem when inline styles are used in HTML tags:
This is a heading
This is a paragraph.
CSP Level 2 browsers may be ok with just putting the hash in your style-src directive. However, to allow hashes in the style attribute on inline CSS on browsers that support CSP Level 3, you may get an error like this
Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='". Either the 'unsafe-inline' keyword, a hash ('sha256-nMxMqdZhkHxz5vAuW/PAoLvECzzsmeAxD/BNwG15HuA='), or a nonce ('nonce-...') is required to enable inline execution.
To allow inline styles you need to use ‘unsafe-hashes’ in your style-src directive (that is, in facts, unsafe).
^
This plugin approach
This plugin affords those problems in this way:
During a capture phase, it detects the scripts, styles and other embedded content present in the pages of your site and stores them in the database.
Then you have to whitelist these contents from plugin admin.
The plugin uses machine learning to cluster inline scripts trying to aggregate scripts generated by the same server side (PHP) code. So, you can authorize one script example to authorize all scripts that the classifier predicts to label as whitelisted clusters.
You can choose to use hashes to authorize external scripts (and the plugin will allow you to include Subresource Integrity in your