跨站請求偽造 (XSRF 或 CSRF)是一個攻擊技術(shù)，它能讓攻擊者假冒一個已認證的用戶在你的網(wǎng)站上執(zhí)行未知的操作。HttpClient 支持一種通用的機制來防范 XSRF 攻擊。當執(zhí)行 HTTP 請求時，一個攔截器會從 cookie 中讀取 XSRF 令牌（默認名字為 XSRF-TOKEN），并且把它設(shè)置為一個 HTTP 頭 X-XSRF-TOKEN，由于只有運行在你自己的域名下的代碼才能讀取這個 cookie，因此后端可以確認這個 HTTP 請求真的來自你的客戶端應(yīng)用，而不是攻擊者。

默認情況下，攔截器會在所有的修改型請求中（比如 POST 等）把這個請求頭發(fā)送給使用相對 URL 的請求。但不會在 GET/HEAD 請求中發(fā)送，也不會發(fā)送給使用絕對 URL 的請求。

要獲得這種優(yōu)點，你的服務(wù)器需要在頁面加載或首個 GET 請求中把一個名叫 XSRF-TOKEN 的令牌寫入可被 JavaScript 讀到的會話 cookie 中。 而在后續(xù)的請求中，服務(wù)器可以驗證這個 cookie 是否與 HTTP 頭 X-XSRF-TOKEN 的值一致，以確保只有運行在你自己域名下的代碼才能發(fā)起這個請求。這個令牌必須對每個用戶都是唯一的，并且必須能被服務(wù)器驗證，因此不能由客戶端自己生成令牌。把這個令牌設(shè)置為你的站點認證信息并且加了鹽（salt）的摘要，以提升安全性。

為了防止多個 Angular 應(yīng)用共享同一個域名或子域時出現(xiàn)沖突，要給每個應(yīng)用分配一個唯一的 cookie 名稱。

注：

HttpClient 支持的只是 XSRF 防護方案的客戶端這一半。 你的后端服務(wù)必須配置為給頁面設(shè)置 cookie，并且要驗證請求頭，以確保全都是合法的請求。如果不這么做，就會導(dǎo)致 Angular 的默認防護措施失效。

配置自定義 cookie/header 名稱

如果你的后端服務(wù)中對 XSRF 令牌的 cookie 或 頭使用了不一樣的名字，就要使用 HttpClientXsrfModule.withConfig() 來覆蓋掉默認值。

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'My-Xsrf-Cookie',
    headerName: 'My-Xsrf-Header',
  }),
],