为什么浏览器不能跨域发送 ajax 请求?

简介: 欢迎关注前端西瓜哥。

大家好,我是前端西瓜哥。最近在写一个网站的小程序,在代码里面请求了其他域名的接口,然后请求失败了,里面涉及到了浏览器安全策略,就作为今天文章的主题吧。

我们在发送 HTTP 请求时,在一些情况下会失败,并且我们会在控制台看到类似下面的错误信息。

Access to XMLHttpRequest at 'http://localhost:3000/users' from origin 'http://localhost:3004' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

这个其实是 跨域问题,即浏览器默认情况下是不允许在一个网站通过 ajax 请求另一个网站的资源的。比如你在 a.com 通过 ajax 请求 b.com/api/v1/user,浏览器会拦截掉返回的数据,然后报错。

这种机制我们称之为同源策略(Same-Origin Poliy)。

什么叫做同源?

只要两个 url 同时满足下面三个条件,我们就认为它们是同源的。

  • 协议相同
  • host 相同
  • 端口相同

当 url 符合同源规则时,浏览器就不会做拦截。

话说回来,HTTP 请求本身是无关域名。

如果你用过命令行工具比如 cURL,或者是一些可视化的接口测试工具如 Postman,你发现任何请求任何域名都不会出现像浏览器这样被拦截的情况。

但浏览器却在请求的过程中做了限制,这其实是为了解决网页过于开放导致的一些安全问题。

为什么浏览器要有同源策略?

我第一次请求一个其他域名的请求时,被浏览器拦截了,说你跨域了。我一脸懵逼,非常困惑。为什么要拦截一个看起来很普通的请求。我只是客户端和服务端部署在不同域名而已,不要这样搞我吧。

当时的我不是很能理解,后来才慢慢明白了原因,选择了原谅它。

对开发来说,受限的功能很让人糟心,但事关安全,还是勉强可以接受的。(但我还想吐槽微信小程序开发)

没有同源策略为什么危险,我们来举个例子。

假设我们回到了浏览器没有使用同源策略的时代,你登录了一个网站 a.com ,比如银行网站,其中的 cookie 保存着你的用户凭证。

然后你打开一个不知名的展示猫猫可爱图片的网站(其实是攻击者的网站)b.com

打开攻击者网站时,其加载的 JS 脚本向网站 a.com 发送了请求 a.com/transfer?userid=xx&amount=99999。因为没有同源策略,浏览器成功发送了这个请求,并带上对应的 cookies。

于是攻击者有了和你一样的权限,获取到你的敏感信息、转走了你的银行余额、删除了你账号上的重要资料。

你很伤心,浏览器看在心里,于是它整了个同源策略,不是相同域名的请求会被拦截检查一下。

还是想跨域

虽然一般情况下跨域的 ajax 并不安全,但有时候我就是想跨域请求一个值得信赖的域名,有办法吗?

有,用 跨源资源共享(CORS, Cross-Origin Resource Sharing)。

简单来说,就是如果请求其他域名接口后,返回的 HTTP 响应头字段中符合特定的规则,浏览器是不会拦截的,此时我们能够正常地拿到返回的数据,就像同源请求一样。

CORS 这个机制非常复杂,我们明天的文章再详细讲解。

结尾

浏览器为防止攻击者跨域冒充已登录的用户发送涉及敏感信息的请求,使用了同源策略(Same-Origin Poliy)。

这样,当你使用 ajax 请求其他域名下的接口时,浏览器就会没收到返回的数据。

当然浏览器也考虑到有些情况下确实要跨域请求,所以也提供了 跨源资源共享(CORS, Cross-Origin Resource Sharing)机制来让一些跨域请求能够正常获得返回的数据。关于 CORS,我们下一篇文章再说。

相关文章
|
4月前
GET与POST之间的差异:为何GET请求的参数在浏览器历史记录中被完整保留,而POST的不被保留?
基于以上,我们可以得出结论:GET请求的参数在浏览器历史记录中之所以能被完整保存,系其请求设计之本质。另一方面,POST请求的参数不被保存,也同样源于其设计目标和工作原理的考虑。
141 12
|
6月前
|
数据采集 存储 运维
无头浏览器与请求签名技术
本文分享了在面对Cloudflare防护(如Amazon网站)时,如何通过无头浏览器、请求签名技术和爬虫代理IP实现数据采集的故障排查与改进方案。首先,介绍了从常规请求失败到引入Selenium无头浏览器的过程,解决了Cookie和User-Agent检测问题。接着,通过生成请求签名绕过二次验证,并利用代理IP规避访问风险。最后,提出了架构改进方案,包括无头浏览器集群化、签名算法优化、代理池管理和多层次容错机制,以提高系统的稳定性和扩展性。示例代码展示了如何设置代理、获取Cookie并生成签名,成功采集商品信息。
180 6
无头浏览器与请求签名技术
|
10月前
|
移动开发 JSON JavaScript
|
11月前
|
Web App开发 JSON 安全
Chrome浏览器的跨域问题
【10月更文挑战第6天】
|
12月前
|
JSON 前端开发 JavaScript
java中post请求调用下载文件接口浏览器未弹窗而是返回一堆json,为啥
客户端调接口需要返回另存为弹窗,下载文件,但是遇到的问题是接口调用成功且不报错,浏览器F12查看居然返回一堆json,而没有另存为弹窗; > 正确的效果应该是:接口调用成功且浏览器F12不返回任何json,而是弹窗另存为窗口,直接保存文件即可。
425 2
|
12月前
|
Web App开发 存储 前端开发
Chrome浏览器的跨域问题
Chrome浏览器的跨域问题
|
缓存 网络协议 安全
揭秘浏览器背后的神秘之旅:一网打尽HTTP请求流程,让你网络冲浪更顺畅!
【8月更文挑战第31天】当在浏览器中输入网址并按下回车键时,一系列复杂的HTTP请求流程随即启动。此流程始于DNS解析,将域名转化为IP地址;接着是与服务器的TCP三次握手建立连接。连接建立后,浏览器发送HTTP请求,其中包含请求方法、资源及版本等信息。服务器接收请求并处理后返回HTTP响应,包括状态码、描述及页面内容。浏览器解析响应,若状态码为200则渲染页面,否则显示错误页。整个流程还包括缓存处理和HTTPS加密等步骤,以提升效率和保障安全。理解该流程有助于更高效地利用网络资源。通过抓包工具如Wireshark,我们能更直观地观察和学习这一过程。
186 4
|
Web App开发 JSON 数据格式
【Azure Developer】浏览器查看本地数据文件时遇见跨域问题(CORS)
【Azure Developer】浏览器查看本地数据文件时遇见跨域问题(CORS)
【Azure Developer】浏览器查看本地数据文件时遇见跨域问题(CORS)
|
Web App开发 JSON 安全
【跨域难题终结者】:一键解锁Chrome浏览器神秘设置,彻底告别开发阶段的跨域烦恼!
【8月更文挑战第20天】跨域是前端开发常遇难题,尤其在前后端分离项目中。浏览器因安全考量会阻止不同源间的请求。本文对比CORS、JSONP、代理服务器等解法,并介绍开发阶段通过调整Chrome设置来临时禁用跨域限制的方法,提供启动Chrome及使用`fetch`API示例,适合快速测试。但请注意这不适用于生产环境,存在一定安全风险。
2594 1
|
缓存 JavaScript 前端开发
浏览器处理预检请求的响应
浏览器处理预检请求的响应