温州微网站公司,网站建设验收要求,做的好点的外贸网站,青岛网站设计品牌企业前言 最近博主在字节面试中遇到这样一个面试题#xff0c;这个问题也是前端面试的高频问题#xff0c;因为在前端开发的日常开发中我们总是会与post请求打交道#xff0c;一个小小的post请求也是牵扯到很多知识点的#xff0c;博主在这给大家细细道来。 #x1f680; 作者… 前言 最近博主在字节面试中遇到这样一个面试题这个问题也是前端面试的高频问题因为在前端开发的日常开发中我们总是会与post请求打交道一个小小的post请求也是牵扯到很多知识点的博主在这给大家细细道来。 作者简介程序员小豪全栈工程师热爱编程曾就职于蔚来、腾讯现就职于某互联网大厂技术栈Vue、React、Python、Java 本文收录于小豪的前端系列专栏后续还会更新前端入门以及前端面试的一些相关文章手把手带你从零学习前端到面试找工作并如果有想进入前端领域工作的同学这个前端专栏会对你有所帮助欢迎关注起来呀 本人也会持续的去关注AIGC以及人工智能领域的一些动向并总结到博客中大家感兴趣的可以关注一下我的人工智能专栏 云原生的入门学习系列大家有兴趣的可以看一看 本文目录 同源策略什么是同源策略 CORS简单请求预检请求附带身份凭证的请求与通配符 完整的请求流程图总结 同源策略
在浏览器中内容是很开放的任何资源都可以接入其中如 JavaScript 文件、图片、音频、视频等资源甚至可以下载其他站点的可执行文件。
但也不是说浏览器就是完全自由的如果不加以控制就会出现一些不可控的局面例如会出现一些安全问题如
跨站脚本攻击XSSSQL 注入攻击OS 命令注入攻击HTTP 首部注入攻击跨站点请求伪造CSRF等等…
如果这些都没有限制的话对于我们用户而言是相对危险的因此需要一些安全策略来保障我们的隐私和数据安全。
这就引出了最基础、最核心的安全策略同源策略。
什么是同源策略
同源策略是一个重要的安全策略它用于限制一个源的文档或者它加载的脚本如何能与另一个源的资源进行交互。
如果两个 URL 的协议、主机和端口都相同我们就称这两个 URL 同源。
协议协议是定义了数据如何在计算机内和之间进行交换的规则的系统例如 HTTP、HTTPS。主机是已连接到一个计算机网络的一台电子计算机或其他设备。网络主机可以向网络上的用户或其他节点提供信息资源、服务和应用。使用 TCP/IP 协议族参与网络的计算机也可称为 IP 主机。端口主机是计算机到计算机之间的通信那么端口就是进程到进程之间的通信。
如下表给出了与 URL http://test.home.com:8080/dir/page.html 的源进行对比的示例
URL结果原因http://test.home.com:8080/dir/page.html同源只有路径不同http://test.home.com:8080/dir/inner/another.html同源只有路径不同https://test.home.com:8080/secure.html不同源协议不同HTTP 和 HTTPShttp://test.home.com:8081/dir/etc.html不同源端口不同http://online.home.com:8080/dir/other.html不同源主机不同
同源策略主要表现在以下三个方面DOM、Web 数据和网络。
DOM 访问限制同源策略限制了网页脚本如 JavaScript访问其他源的 DOM。这意味着通过脚本无法直接访问跨源页面的 DOM 元素、属性或方法。这是为了防止恶意网站从其他网站窃取敏感信息。Web 数据限制同源策略也限制了从其他源加载的 Web 数据例如 XMLHttpRequest 或 Fetch API。在同源策略下XMLHttpRequest 或 Fetch 请求只能发送到与当前网页具有相同源的目标。这有助于防止跨站点请求伪造CSRF等攻击。网络通信限制同源策略还限制了跨源的网络通信。浏览器会阻止从一个源发出的请求获取来自其他源的响应。这样做是为了确保只有受信任的源能够与服务器进行通信以避免恶意行为。
出于安全原因浏览器限制从脚本内发起的跨源 HTTP 请求XMLHttpRequest 和 Fetch API只能从加载应用程序的同一个域请求 HTTP 资源除非使用 CORS 头文件
CORS
对于浏览器限制这个词要着重解释一下不一定是浏览器限制了发起跨站请求也可能是跨站请求可以正常发起但是返回结果被浏览器拦截了。
浏览器将不同域的内容隔离在不同的进程中网络进程负责下载资源并将其送到渲染进程中但由于跨域限制某些资源可能被阻止加载到渲染进程。如果浏览器发现一个跨域响应包含了敏感数据它可能会阻止脚本访问这些数据即使网络进程已经获得了这些数据。CORB 的目标是在渲染之前尽早阻止恶意代码获取跨域数据。 CORB 是一种安全机制用于防止跨域请求恶意访问跨域响应的数据。渲染进程会在 CORB 机制的约束下选择性地将哪些资源送入渲染进程供页面使用。 例如一个网页可能通过 AJAX 请求从另一个域的服务器获取数据。虽然某些情况下这样的请求可能会成功但如果浏览器检测到请求返回的数据可能包含恶意代码或与同源策略冲突浏览器可能会阻止网页访问返回的数据以确保用户的安全。
跨源资源共享Cross-Origin Resource SharingCORS是一种机制允许在受控的条件下不同源的网页能够请求和共享资源。由于浏览器的同源策略限制了跨域请求CORS 提供了一种方式来解决在 Web 应用中进行跨域数据交换的问题。
CORS 的基本思想是服务器在响应中提供一个标头HTTP 头指示哪些源被允许访问资源。浏览器在发起跨域请求时会先发送一个预检请求OPTIONS 请求到服务器服务器通过设置适当的 CORS 标头来指定是否允许跨域请求并指定允许的请求源、方法、标头等信息。
简单请求
不会触发 CORS 预检请求。这样的请求为 简单请求。若请求满足所有下述条件则该请求可视为 简单请求
HTTP 方法限制只能使用 GET、HEAD、POST 这三种 HTTP 方法之一。如果请求使用了其他 HTTP 方法就不再被视为简单请求。自定义标头限制请求的 HTTP 标头只能是以下几种常见的标头Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type仅限于 application/x-www-form-urlencoded、multipart/form-data、text/plain。HTML 头部 header field 字段DPR、Download、Save-Data、Viewport-Width、WIdth。如果请求使用了其他标头同样不再被视为简单请求。请求中没有使用 ReadableStream 对象。不使用自定义请求标头请求不能包含用户自定义的标头。请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问
预检请求
非简单请求的 CORS 请求会在正式通信之前增加一次 HTTP 查询请求称为 预检请求。
需预检的请求要求必须首先使用 OPTIONS 方法发起一个预检请求到服务器以获知服务器是否允许该实际请求。预检请求 的使用可以避免跨域请求对服务器的用户数据产生未预期的影响。
例如我在自己的网站上删除一条记录: 它首先会发起一个预检请求,预检请求的头信息包括两个特殊字段
Access-Control-Request-Method该字段是必须的用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法上例是 POST。Access-Control-Request-Headers该字段是一个逗号分隔的字符串指定浏览器 CORS 请求会额外发送的头信息字段上例是 content-type,x-secsdk-csrf-token。access-control-allow-origin在上述例子中表示 https://xxx.cn 可以请求数据也可以设置为* 符号表示统一任意跨源请求。access-control-max-age该字段可选用来指定本次预检请求的有效期单位为秒。上面结果中有效期是 1 天86408 秒即允许缓存该条回应 1 天86408 秒在此期间不用发出另一条预检请求。
一旦服务器通过了 预检请求以后每次浏览器正常的 CORS 请求就都跟简单请求一样会有一个 Origin 头信息字段。服务器的回应也都会有一个 Access-Control-Allow-Origin 头信息字段。 上面头信息中Access-Control-Allow-Origin 字段是每次回应都必定包含的。
附带身份凭证的请求与通配符
在响应附带身份凭证的请求时
为了避免恶意网站滥用 Access-Control-Allow-Origin 头部字段来获取用户敏感信息服务器在设置时不能将其值设为通配符 *。相反应该将其设置为特定的域例如Access-Control-Allow-Origin: https://xxx.cn。通过将 Access-Control-Allow-Origin 设置为特定的域服务器只允许来自指定域的请求进行跨域访问。这样可以限制跨域请求的范围避免不可信的域获取到用户敏感信息。为了避免潜在的安全风险服务器不能将 Access-Control-Allow-Headers 的值设为通配符 *。这是因为不受限制的请求头可能被滥用。相反应该将其设置为一个包含标头名称的列表例如Access-Control-Allow-Headers: X-PINGOTHER, Content-Type。通过将 Access-Control-Allow-Headers 设置为明确的标头名称列表服务器可以限制哪些自定义请求头是允许的。只有在允许的标头列表中的头部字段才能在跨域请求中被接受。为了避免潜在的安全风险服务器不能将 Access-Control-Allow-Methods 的值设为通配符 *。这样做将允许来自任意域的请求使用任意的 HTTP 方法可能导致滥用行为的发生。相反应该将其设置为一个特定的请求方法名称列表例如Access-Control-Allow-Methods: POST, GET。通过将 Access-Control-Allow-Methods 设置为明确的请求方法列表服务器可以限制哪些方法是允许的。只有在允许的方法列表中的方法才能在跨域请求中被接受和处理。对于附带身份凭证的请求通常是 Cookie
这是因为请求的标头中携带了 Cookie 信息如果 Access-Control-Allow-Origin 的值为 *请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 https://xxx.cn则请求将成功执行。
另外响应标头中也携带了 Set-Cookie 字段尝试对 Cookie 进行修改。如果操作失败将会抛出异常。
完整的请求流程图 总结
预检请求是在进行跨域资源共享 CORS 时由浏览器自动发起的一种 OPTIONS 请求。它的存在是为了保障安全并允许服务器决定是否允许跨域请求。
跨域请求是指在浏览器中向不同域名、不同端口或不同协议的资源发送请求。出于安全原因浏览器默认禁止跨域请求只允许同源策略。而当网页需要进行跨域请求时浏览器会自动发送一个预检请求以确定是否服务器允许实际的跨域请求。
预检请求中包含了一些额外的头部信息如 Origin 和 Access-Control-Request-Method 等用于告知服务器实际请求的方法和来源。服务器收到预检请求后可以根据这些头部信息进行验证和授权判断。如果服务器认可该跨域请求将返回一个包含 Access-Control-Allow-Origin 等头部信息的响应浏览器才会继续发送实际的跨域请求。
使用预检请求机制可以有效地防范跨域请求带来的安全风险保护用户数据和隐私。
