跨域這兩個字就像一塊狗皮膏藥一樣黏在每一個前端開發者身上，無論你在工作上或者面試中無可避免會遇到這個問題。為了應付面試，我每次都隨便背幾個方案，也不知道為什么要這樣干，反正面完就可以扔了，我想工作上也不會用到那么多亂七八糟的方案。到了真正工作，開發環境有webpack-dev-server搞定，上線了服務端的大佬們也會配好，配了什么我不管，反正不會跨域就是了。日子也就這么混過去了，終于有一天，我覺得不能再繼續這樣混下去了，我一定要徹底搞懂這個東西！于是就有了這篇文章。

要掌握跨域，首先要知道為什么會有跨域這個問題出現

確實，我們這種搬磚工人就是為了混口飯吃嘛，好好的調個接口告訴我跨域了，這種阻礙我們輕松搬磚的事情真惡心！為什么會跨域？是誰在搞事情？為了找到這個問題的始作俑者，請點擊：瀏覽器的同源策略。

這么官方的東西真難懂，沒關系，至少你知道了，因為瀏覽器的同源策略導致了跨域，就是瀏覽器在搞事情。

所以，瀏覽器為什么要搞事情？就是不想給好日子我們過？對于這樣的質問，瀏覽器甩鍋道：“同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用于隔離潛在惡意文件的重要安全機制。”

這么官方的話術真難懂，沒關系，至少你知道了，似乎這是個安全機制。

所以，究竟為什么需要這樣的安全機制？這樣的安全機制解決了什么問題？別急，讓我們繼續研究下去。

沒有同源策略限制的兩大危險場景

據我了解，瀏覽器是從兩個方面去做這個同源策略的，一是針對接口的請求，二是針對Dom的查詢。試想一下沒有這樣的限制上述兩種動作有什么危險。

沒有同源策略限制的接口請求

有一個小小的東西叫cookie大家應該知道，一般用來處理登錄等場景，目的是讓服務端知道誰發出的這次請求。如果你請求了接口進行登錄，服務端驗證通過后會在響應頭加入Set-Cookie字段，然后下次再發請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中，服務端就能知道這個用戶已經登錄過了。知道這個之后，我們來看場景：

你準備去清空你的購物車，于是打開了買買買網站www.maimaimai.com，然后登錄成功，一看，購物車東西這么少，不行，還得買多點。
你在看有什么東西買的過程中，你的好基友發給你一個鏈接www.nidongde.com，一臉yin笑地跟你說：“你懂的”，你毫不猶豫打開了。
你饒有興致地瀏覽著www.nidongde.com，誰知這個網站暗地里做了些不可描述的事情！由于沒有同源策略的限制，它向www.maimaimai.com發起了請求！聰明的你一定想到上面的話“服務端驗證通過后會在響應頭加入Set-Cookie字段，然后下次再發請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中”，這樣一來，這個不法網站就相當于登錄了你的賬號，可以為所欲為了！如果這不是一個買買買賬號，而是你的銀行賬號，那……
這就是傳說中的CSRF攻擊。

看了這波CSRF攻擊我在想，即使有了同源策略限制，但cookie是明文的，還不是一樣能拿下來。于是我看了一些cookie相關的文章：聊一聊 cookie、Cookie/Session的機制與安全，知道了服務端可以設置httpOnly，使得前端無法操作cookie，如果沒有這樣的設置，像XSS攻擊就可以去獲取到cookie（Web安全測試之XSS）；設置secure，則保證在https的加密通信中傳輸以防截獲。

沒有同源策略限制的Dom查詢

有一天你剛睡醒，收到一封郵件，說是你的銀行賬號有風險，趕緊點進www.yinghang.com改密碼。你嚇尿了，趕緊點進去，還是熟悉的銀行登錄界面，你果斷輸入你的賬號密碼，登錄進去看看錢有沒有少了。
睡眼朦朧的你沒看清楚，平時訪問的銀行網站是www.yinhang.com，而現在訪問的是www.yinghang.com，這個釣魚網站做了什么呢？
// HTML

// JS // 由于沒有同源策略的限制，釣魚網站可以直接拿到別的網站的Dom const iframe = window.frames['yinhang'] const node = iframe.document.getElementById('你輸入賬號密碼的Input') console.log(`拿到了這個${node}，我還拿不到你剛剛輸入的賬號密碼嗎`) 由此我們知道，同源策略確實能規避一些危險，不是說有了同源策略就安全，只是說同源策略是一種瀏覽器最基本的安全機制，畢竟能提高一點攻擊的成本。其實沒有刺不穿的盾，只是攻擊的成本和攻擊成功后獲得的利益成不成正比。

總結

以上是生活随笔為你收集整理的什么是跨域？一次性带你理解透的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。