一、跨域
1、當兩個域具有相同的協議(如http), 相同的端口(如80)，相同的host（如www.google.com)，那麼我們就可以認爲它們是相同的域（協議，域名，端口都必須相同）。
2、跨域就指着協議，域名，端口不一致，出於安全考慮，跨域的資源之間是無法交互的(例如一般情況跨域的JavaScript無法交互，當然有很多解決跨域的方案)
二、導致跨域的原因：同源策略
跨域的出現是因爲瀏覽器的同源策略的限制，出發點是爲了安全起見
同源策略的方向一是針對接口的請求，二是針對Dom的查詢。
1、沒有同源策略限制的接口請求
我們一般用cookie來處理登錄場景，目的是讓服務端知道誰發出的這次請求。如果你請求了接口進行登錄，服務端驗證通過後會在響應頭加入Set-Cookie字段，然後下次再發請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中，服務端就能知道這個用戶已經登錄過了。
假如我們在一個涉及到我們隱私的正規網站中訪問，突然不知道從哪彈出一個鏈接，不管是有意還是無意，我們點開了這個莫名其妙的網址（惡意網站），由於沒有同源策略的限制，它向我們正經的網址中發起了請求，由cookie驗證我們可以知道“服務端驗證通過後會在響應頭加入Set-Cookie字段，然後下次再發請求的時候，瀏覽器會自動將cookie附加在HTTP請求的頭字段Cookie中”，這樣一來，這個惡意網站就相當於登錄了我們的賬號，有了我們的個人信息，這是很危險的，他們可以隨意使用我們的個人信息，後果可想而知.....這種跨站請求僞造就是我們常說的CSRF攻擊
看了這波CSRF攻擊我在想，即使有了同源策略限制，但cookie是明文的，還不是一樣能拿下來。於是我看了一些cookie相關的文章聊一聊 cookie、Cookie/Session的機制與安全，知道了服務端可以設置httpOnly，使得前端無法操作cookie，如果沒有這樣的設置，像XSS攻擊就可以去獲取到cookieWeb安全測試之XSS；設置secure，則保證在https的加密通信中傳輸以防截獲。
2、沒有同源策略限制的Dom查詢
某天我們突然收到一條短信，說自己的某賬號出現非法登錄，需要緊急修改，慌亂之下我們匆匆點擊去一頓修改（包含賬號及密碼的驗證），殊不知我們這是在主動送人頭【由於沒有同源策略的限制，惡意網站是可以拿到別的正經網站的dom，即能獲取到我們的賬戶信息】，被別人坑害了，還暗自慶幸自己機智.....
瞭解沒有同源策略限制的危害後就知道還是有必要增加跨域限制的
三、處理跨域
1、情況描述
Web項目中調用一個與Web不同域名與端口的接口，出現跨域
2、原代碼及結果
（1）Web項目的請求
（2）接口的內容
（3）訪問結果：跨域限制
3、處理（在後臺處理）
（1）在接口裏增加以下代碼：表示所有的域都可以訪問
response.setHeader("Access-Control-Allow-Origin", "*");
4、訪問結果：成功跨域並返回結果
