绝大部分开发者在其间端分立的情景下，都碰到过应用程序布吕马难题，接着在网路上搜了两个实用性就化解了。但，你吗介绍布吕马整件事吗？而你找出的实用性又做甚么？

看呵呵这两个难题，试验呵呵你的认知某种程度。

1. 甚么是布吕马？和CORS是甚么亲密关系？

CORS 是化解应用程序布吕马管制的计划众所周知。

布吕马: 单纯而言是指应用程序在domain-a.com的搜索引擎下，促发器读取非现阶段出访搜索引擎(e.g: domain-b.com)下的天然资源。假如协定+搜索引擎+freenode均完全相同，则是草同域，不然，则是布吕马。

CORS:Cross-origin resource sharing (跨源数据共享) （或浅显地译为布吕马数据共享）是一类如前所述HTTP 头的监督机制，该监督机制透过容许伺服器标注除它他们之外的其他origin（域，协定和路由器），这种应用程序能出访读取那些天然资源。

2. 假如透过curl间接允诺USB，并在header中减少origin，与否有布吕马管制？

不会。布吕马管制是应用程序行为。

服务端能透过Request Header中的Origin判断与否布吕马。假如服务端不做管制，应用程序的允诺也会被执行，并返回结果。但应用程序会解析Response中的header与否包含Access-Control-Allow-Origin且Value与现阶段同源，不然不会解析response body并抛出CORS error

Origin在CORS或POST允诺中才存在。

3. 为甚么有布吕马管制？

假如容许布吕马，用户可能会遭到CSRF攻击。

跨站允诺伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一类挟制用户在现阶段已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页应用程序的信任。

一个典型情景是，假如你在透过web应用程序出访email邮箱，点开了某个奇怪的链接，而这个链接则是自动向你的email邮箱伺服器提交某个规则变更允诺。假如没有布吕马管制，则伺服器判断为是你本人在登陆状态下发送的变更允诺，而这个变更可能导致你的邮件全部被转发到攻击者邮箱内。

另一个经典情景则是iframe包裹真实网站，诱导用户进行敏感操作

4. 甚么这时候会促发挂号(PreFlight by OPTIONS)监督机制？

挂号允诺先使用 OPTIONS 方法发起一个挂号允诺到伺服器，以获知伺服器与否容许该实际允诺。”挂号允诺”的使用，能避免布吕马允诺对伺服器的用户数据产生未预期的影响。

以Spring为例，假如挂号允诺不透过，则会间接返回403阻止后续继续发送实际允诺。

允诺会界定单纯允诺和挂号允诺。非单纯允诺都会促发挂号操作。

单纯允诺包括但不局限

5. 怎样界定OPTIONS允诺和挂号(PreFlight)

挂号允诺 会在header中减少Access-Control-Request-Method

比如布吕马允诺put允诺，则会先发送一个 OPTIONS 允诺，且header包括Access-Control-Request-Method=PUT

6. 布吕马允诺会随身携带cookie重要信息吗？

默认不会发送，能透过设置withCredentials = true;

让客户端发送cookie重要信息。

同时，为了避免误用导致的安全性难题，假如设置了allowCredentials，则不容许将Access-Control-Allow-Origin设置通配符*，只能设置具体的某个源。

Spring5.3版本提供了相关管制