萬維網的安全策略植根於同源策略。例如www.jb51.net的程式碼只能存取www.jb51.net的數據，而沒有存取http://www.baidu.com的權限。每個來源都與網路的其它部分分隔開，為開發人員建立了一個安全的沙箱。理論上這是完美的，但是現在攻擊者已經找到了聰明的方式來破壞這個系統。
這是XSS跨站腳本攻擊，並透過虛假內容和誘騙點擊來繞過同源策略。這是一個很大的問題，如果攻擊者成功注入程式碼，有相當多的用戶資料會被洩漏。
現在我們介紹一個全新的、有效的安全防禦策略來減輕這種風險，這就是內容安全策略（ContentSecurity Policy，CSP）。
來源白名單
XSS攻擊的核心是利用了瀏覽器無法區分腳本是被第三方註入的，還是真的是你應用程式的一部分。例如Google 1按鈕會從https://apis.google.com/js/plusone.js載入並執行程式碼，但我們不能指望從瀏覽器上的圖片就能判斷出程式碼是真的來自apis.google.com ，還是來自apis.evil.example.com。瀏覽器下載並執行任意程式碼的頁面請求，而不論其來源。
CSP定義了Content-Security-PolicyHTTP頭來允許你創建一個可信任來源的白名單，使得瀏覽器只執行和渲染來自這些來源的資源，而不是盲目信任伺服器提供的所有內容。即使攻擊者可以找到漏洞來注入腳本，但是因為來源不包含在白名單裡，因此將不會被執行。
以上面Google 1按鈕為例，因為我們相信apis.google.com提供有效的程式碼，以及我們自己，所以可以定義一個策略，允許瀏覽器只會執行下面兩個來源之一的腳本。
Content-Security-Policy:script-src 'self' https://apis.google.com
是不是很簡單？ script-src可以為指定頁面控制腳本相關權限。這樣瀏覽器只會下載和執行來自http://apis.google.com和本頁本身的腳本。
一旦我們定義了這個策略，瀏覽器會在偵測到注入程式碼時拋出一個錯誤（請注意是什麼瀏覽器）。
內容安全策略適用於所有常用資源
雖然腳本資源是最明顯的安全隱患，但CSP也提供了一套豐富的指令集，允許頁面控制載入各種類型的資源，例如如下的類型：
content-src：限制連線的類型（例如XHR、WebSockets和EventSource）
font-src：控製網頁字體的來源。例如可以透過font-src https://themes.googleusercontent.com來使用Google的網頁字體。
frame-src：列出了可以嵌入的frame的來源。例如frame-src https://youtube.com只允許嵌入YouTube的影片。 。
img-src：定義了可載入圖片的來源。
media-src：限制視訊和音訊的來源。
object-src：限制Flash和其他外掛程式的來源。
style-src：類似Script-src，只是作用於css檔案。
預設情況下，所有的設定都是開啟的，並不做任何限制。你可以以分號分隔多個指令，但類似script-src https://host1.com;script-src https://host2.com的形式，第二個指令將會被忽略。正確的寫法是script-src https://host1.com https://host2.com。
例如，你有一個應用程式需要從內容分發網路（CDN，例如https://cdn.example.net）載入所有的資源，並且知道不需要任何frame和插件的內容，你的策略可能會像下面這樣：
Content-Security-Policy:default-src https://cdn.example.net; frame-src 'none'; object-src 'none'
細部
的HTTP頭是Content-Security-Policy，但現代瀏覽器已經透過前綴來提供了支援：Firefox使用x-Content-Security-Policy，WebKit使用X-WebKit-CSP。未來將逐步過渡到統一的標準。
策略可依每個不同的頁面設定，這提供了極大的彈性。因為你的網站可能有的頁面有Google 1的按鈕，而有的則沒有。
每個指令的來源清單可以相當靈活，你可以指定模式（data:, https:），或指定主機名在一個範圍（example.com，它匹配主機上的任意來源、任意模式和任意端口），或指定一個完整的URI（https://example.com:443，特別指https協議，example.com域名，443埠）。
你在來源清單中也可以使用四個關鍵字：
「none」：你可能會期望不符合任何內容
「self」：與目前來源相同，但不包含子網域
「unsafe- inline」：允許內嵌Javascript和CSS
「unsafe-eval」：允許文字到JS的機制例如eval
請注意，這些關鍵字需要加引號。
沙箱
這裡還有另一個值得討論的指示：sandbox。和其他指令有些不一致，它主要是控制頁面上採取的行為，而不是頁面能夠載入的資源。如果設定了這個屬性，頁面就表現為一個設定了sandbox屬性的frame一樣。這對頁面有很大範圍的影響，例如防止表單提交等。這有點超出了本文的範圍，但你可以在HTML5規範的「沙箱標誌設定」章節找到更多資訊。
有害的內嵌程式碼
CSP基於來源白名單，但它不能解決XSS攻擊的最大來源：內聯腳本注入。如果攻擊者可以注入包含有害程式碼的script標籤（
），瀏覽器並沒有好的機制來區分這個標籤。 CSP只能透過完全禁止內聯腳本來解決這個問題。 這個禁止項不僅包括腳本中嵌入的script標籤，還包括內聯事件處理程序和javascrpt:這種URL。你需要把script標籤的內容放到一個外部文件裡，並且用適當的addEventListener的方式取代javascript:和
。例如，你可能會把下面的表單：
Am I amazing?
重寫為下面的形式：
Am I amazing?
// amazing.js
function doAmazingThings() {
alert('YOU AM AM AM AMING!');
}
document.addEventListener('DOMContentReady', function () {
document.getElementById('amazing')
無論是否使用CSP，以上的程式碼其實有更大的優點。內嵌JavaScript完全混合了結構和行為，你不應該這麼做。另外外聯資源更容易進行瀏覽器緩存，開發者更容易理解，便於編譯和壓縮。如果採用外聯程式碼，你會寫出更好的程式碼。
內嵌樣式需要以相同的方式處理，無論是style屬性或style標籤都需要擷取到外部樣式表中。這樣可以防止各式各樣神奇的資料外洩方式。
如果你必須要有內嵌腳本和樣式，可以為script-src or style-src屬性設定'unsafe-inline值。但不要這樣做，禁止內聯腳本是CSP提供的最大安全保證，同時禁止內聯樣式可以讓你的應用變得更加安全和健壯。這是一個權衡，但是非常值得。
Eval
即使攻擊者不能直接注入腳本，他可能會誘使你的應用程式把插入的文字轉換為可執行腳本並且自我執行。 eval() , newFunction() , setTimeout([string], ...) 和setInterval([string], ...) 都可能成為這種危險的載體。 CSP針對這種風險的策略是，完全阻止這些載體。
這對你建構應用的方式有一些影響：
以內建的JSON.parse解析JSON，且不依賴於eval。 IE8以後的瀏覽器都支援本地JSON操作，這是完全安全的。
以內嵌函數取代字串來重寫你setTimeout和setInterval的呼叫方式。例如：
setTimeout("document.querySelector('a').style.display = 'none';", 10);
('a').style.display = 'none'; }, 10);
避免使用期間的內嵌模版：許多模版函式庫使用new Function()來加速模版的產生。這對動態程式來說非常棒，但是對惡意文字來說存在風險。
報告
CSP可以在伺服器端阻止不可信的資源對用戶來說非常有用，但是對於獲取各種發送到伺服器的通知來說對我們卻非常有用，這樣我們就能識別和修復任何惡意腳本注入。為此你可以透過report-uri指令指示瀏覽器發送JSON格式的攔截報告到某個位址。
Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
報告看起來會像下面這樣：
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrerer ": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.js",
"violated-directive": " script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com; report-uri http:// example.org/my_amazing_csp_report_parser"
}
}
其中包含的資訊會幫助你識別攔截的情況，包括攔截發生的頁面（document-uri），頁面的referrer，違反頁面的referrer，違反策略的資源blocked-uri），所違反的指令（violated-directive）以及頁面所有的內容安全策略（original-policy）。
現實用法
CSP現在在Chrome 16 和Firefox 4 的瀏覽器上可用，並且它在IE10上預計會獲得有限的支援。 Safari目前還不支持，但是WebKit每晚建置版已經可用，所以預計Safari將會在下面的迭代中提供支援。
以下讓我們來看一些常用的使用案例：
實際案例1：社會化媒體widget
Google 1 button包括來自https://apis.google.com的腳本，以及嵌入自:// plusone.google.com的iframe。你的策略需要包含這些來源來使用Google 1的按鈕。最簡單的策略是script-src https://apis.google.com; frame-src https://plusone.google.com。你還需要確保Google提供的JS片段存放在外部的JS檔案裡。
Facebook的Like按鈕有許多種實現方案。我建議你堅持使用iframe版本，因為它可以和你網站的其它部分保持很好的隔離。這需要使用frame-src https://facebook.com指令。請注意，預設情況下，Facebook提供的iframe程式碼使用的是相對路徑//facebook.com，請把這段程式碼修改為https://facebook.com，HTTP你沒有必要可以不使用。
Twitter的Tweet按鈕依賴script和frame，都來自於https://platform.twitter.com（Twitter預設提供的是相對URL，請在複製的時候編輯程式碼來指定為HTTPS方式）。
其它的平台有類似的狀況，可以類似的解決。我建議把default-src設定為none，然後查看控制台來檢查你需要使用哪些資源來確保widget正常運作。
使用多個widget非常簡單：只需要合併所有的策略指令，記得把相同指令的設定都放在一起。如果你想使用上面這三個widget，策略看起來會像下面這樣：
script-src https://apis.google.com https://platform.twitter.com; frame-src https:// plusone.google.com https://facebook.com https://platform.twitter.com
實際案例2：防禦
假設你存取一個銀行網站，並且希望確保只載入你所需的資源。在這種情況下，開始設定一個預設的權限來阻止所有的內容（default-src ‘none’），並且從這從頭開始建立策略。
例如，銀行網站需要從來自https://cdn.mybank.net的CDN載入圖片、樣式和腳本，並且透過XHR連接到https://api.mybank.com/來拉取各種數據，還需要使用frame，但是frame都來自非第三方的本機頁面。網站上沒有Flash、字體和其他內容。這種情況下我們可以發送最嚴格的CSP頭是：
Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https:// cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; frame-src 'self'
實際案例3：只使用SSL
一個婚戒論壇管理員希望所有的資源都通過安全的方式進行加載，但是不想真的編寫太多代碼；重寫大量第三方論壇內聯腳本和样式的代碼超出了他的能力。所以以下的策略將會是非常有用的：
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
儘管default-src指定了https，腳本和樣式不會自動繼承。每個指令將會完全覆蓋預設資源類型。
未來
W3C的Web應用安全工作小組正在製定內容安全策略規範的細節，1.0版本將要進入最後修訂階段，它和本文描述的內容已經非常接近。而public-webappsec@郵件群組正在討論1.1版本，瀏覽器廠商也在努力鞏固和改進CSP的實作。
CSP 1.1在畫板上有一些有趣的地方，值得單獨列出來：
透過meta標籤新增策略：CSP的首選設定方式是HTTP頭，它非常有用，但是透過標記或腳本設定會更直接，不過目前還未最終確定。 WebKit已經實現了透過meta元素進行權限設定的特性，所以你現在可以在Chrome下嘗試如下的設定：在文件頭添加
你甚至可以在執行時透過腳本來新增策略。
DOM API：如果CSP的下一個迭代加入了這個特性，你可以透過Javascript來查詢頁面目前的安全策略，並根據不同的情況進行調整。例如在eval()是否可用的情況下，你的程式碼實作可能會有些許不同。這對JS框架的作者來說非常有用；而且API規範目前還非常不確定，你可以在規範草案的腳本介面章節找到最新的迭代版本。
新的指令：許多新指令正在討論中，包括script-nonce：只有明確指定的腳本元素才能使用內聯腳本；plugin-types：這將限制插件的類型；form-action：允許form只能提交到特定的來源。
如果你對這些未來特色的討論有興趣，可以閱讀郵件清單的歸檔或加入郵件清單。
本文譯自：http://www.html5rocks.com/en/tutorials/security/content-security-policy/
摘自：蔣宇捷的部落格
