自從我們執行了第一個前100萬個安全頭報告以來，差不多整整一年了，所以現在是重新運行分析的好時機，看看安全頭的採用情况有多好。和以前一樣，最新的Chrome和Firefox用戶代理字串用於通過HTTP和HTTPS向排名前100萬的網站發出請求。在2589918個響應中，我們有超過100000個不同的安全頭和值需要分析。與之前的掃描相比，我們有514288個與2012年11月第一次運行時匹配的URL，以及從2013年3月開始匹配的1207169個URL。這一次，我們添加了另一個安全標題“X-XSS-Protection”，這是由於來自此部落格上的一個評論者的請求。不幸的是，我們沒有在以前的任何掃描中存儲此頭，囙此無法比較其採用率。

更改、添加和删除年度審查

在一年的時間裏，共有7258個新的安全頭被添加到兩個數據集中的514288個url中。與之前一樣，我們看到X-Frame-Options和CORS標頭檔的新增幅度最大。在不遠處的第四個網站中，我們看到嚴格的傳輸安全性穩步上升，538個新網站使用了標頭檔。儘管X-Content-Security-Policy和X-WebKit-CSP已被弃用，但我們仍然看到它們的添加量略有新增。同樣，使用率最高的郵件頭也會在一年中從365個網站中删除最多的X-Frame-Options。您可能會注意到，內容安全性原則頭在年度檢查中遺失，這是因為在我們首次開始此分析時，它不是標準化的。為了瞭解標準化CSP的採用率，我們需要對比一下2013年3月進行的掃描。

2013年3月起的變更、新增和删除

自去年3月以來，我們有很多匹配的url，但令人驚訝的是，圖表看起來非常相似。在這次運行和2013年3月之間匹配的1207169個URL中添加了7099個新的安全頭。在這些網站中，有62個網站啟用了內容安全性原則，其中47個網站啟用了即將禁用的X-Content-Security-Policy頭，這一數位令人失望。雖然看到CSP的採用率新增會很高興，但對於任何一個網站來說，創建一個符合規定的政策都是一個巨大的任務，這是完全可以理解的。

2013年11月業績

X-XSS-保護

這次又有一個標題被添加到分析中。Microsoft認可的標題是為了允許網站控制如何在逐個資源的基礎上處理Internet Explorer的XSS篩選功能。X-XSS-Protection的有效值如下：

• 0-禁用XSS保護
• 1-啟用XSS保護，即篩選器將嘗試清除潜在的惡意字元。
• 1、mode=block-啟用XSS保護並訓示IE封锁響應，而不是清除。
• 1、report=[url]-允許將報告發送到潜在XSS嘗試的指定url。

需要注意的是，如果資源以0作為X-X s s-Protection頭的值進行響應，那麼Google Chrome的XSS Auditor也將被禁用。前面的讀者會記得，無效的頭值是一個嚴重的問題，X-XSS-Protection也不例外。幾乎480個網站錯誤地指定了“0；mode=block”的值。這意味著477個認為自己在封锁XSS攻擊的網站正在積極禁用IE和Chrome內寘的XSS保護。請注意，使用X-XSS-Protection的url中，YouTube和Blogspot占了大多數，YouTube和Blogspot分別為14210和18587。

X框選項

X-Frame-Options仍然保持強勢，SAMEORIGIN是現時最大的設定，YouTube再次佔據了大多數，擁有14178個url，所有url都設定為SAMEORIGIN。除了使用X-Frame-Options跳轉網站之外，我們還看到配寘的無效值新增。

跨源請求共亯（CORS）頭

我們再次查看了兩個CORS頭：Access Control Allow Origin和Access Control Allow Credentials。不幸的是，我們仍然看到大量網站通過指定萬用字元或由不同字元分隔的多個源來錯誤配寘存取控制允許源。作為提醒，存取控制Allow Origin只允許*（萬用字元值）或指定有效方案的單個Origin。至於存取控制允許憑據，1388個網站已將該值設定為true，51個網站設定為false。令人驚訝的是，我們發現196個網站設定了萬用字元源訪問，但設定存取控制允許憑據為true，這是無效的設定組合。

嚴格的運輸安全

根據讀者的建議，我們將long max age值更改為任何大於604800秒或7天的值。同樣，下麵的值被認為是一個短的最大年齡。Facebook和Etsy分別包含74和61個url，在maxageof0列中。提醒一下，頭值為0將從瀏覽器的嚴格傳輸安全緩存中清除域。在更有趣的無效值中，大量網站錯誤地將“，”用作max age value和includeSubDomains指令之間的分隔符號。不幸的是，Firefox和Chrome在這方面都非常嚴格，如果使用“，”字元而不是RFC定義的“；”標記，它們將拒絕將網站添加到STS緩存。在實現這些安全頭之前，請再次檢查RFC。

內容安全性原則

內容安全性原則的使用量繼續增長，但增長極為緩慢。只有269個網站使用w3規範的內容安全性原則頭，其中95個來自Facebook。有趣的是，584個網站使用X-Content-Security-Policy，487個網站使用X-Webkit-CSP。應該注意的是，這兩個標頭檔已經被視為不推薦使用，但尚未被禁用。只觀察到極少數使用僅報告版本的CSP頭的網站。預計希望測試CSP的網站運營商將使用僅報告模式來確定內容安全性原則將如何影響其網站，但我們僅看到24個網站使用僅內容安全性原則報告。CSP分析的最有趣的結果是大量網站使用CSP和不安全指令。不安全內聯之所以有如此高的使用率，是因為開發人員很難從web頁面元素中删除所有內聯腳本。儘管令人失望，但任何試圖製定嚴格的顧客服務提供者政策的人都可以理解。

結論

可以肯定地說，我們還有很長的路要走，以確保我們的網站使用所有可用的手段來保護自己。雖然安全頭只是防禦的一小部分，但適當地應用它們可以並且確實幫助我們都成為更安全的互聯網用戶。在看到數位不斷增長的同時，我們必須記住，在分析的2589918個url中，只有不到10%（199350）的url具有安全頭。雖然嚴格遵守RFC是必要的，但是輸入錯誤，再加上指令解析的嚴格性，在遇到這些標題時對網站管理員或用戶沒有幫助。雖然不應該放弃對CSP的希望，但它的採用率非常低，值得考慮創建工具來幫助創建、驗證和支持希望採用CSP的網站管理員。與之前一樣，Veracode已經發佈了這一分析的原始數據，囙此請在這裡下載2013年11月的結果。