restkhz

@raw0xff 你没搞明白的是谁在防谁。
这个机制不是让你服务器防着恶意客户，而是让正常客户防第三方网站的攻击。防止第三方攻击者在正常客户的浏览器中模拟正常请求访问你的接口。这个是在保护浏览器安全，不是保护服务器安全。

你的客户可能在第三方网站被钓鱼，假设没有同源策略，假设你是银行，此时恶意的第三方网站里有个脚本会在用户浏览器里运行：自动模拟你网站的转账操作，发给你的接口。由于没有同源策略，这个请求因为带着你客户的 cookie 等信息。你的客户就这样莫名其妙被偷了钱。

或者你是一个 webmail 但是人家也可以通过类似手段，在三方钓鱼网站里插脚本控制用户浏览器，进而偷到你客户的邮件。

你说请求在接口处理与否取决于你的代码，但是这个伪造的请求千真万确是客户端浏览器发的。看似完全正常的请求，正常的 Cookie ，同样的 IP 。Referer 头不靠谱而且可能被绕过，你说用 Token 但是 Token 也可能被偷(如果没有同源策略)。你服务器要怎么检查？？

因为这种攻击发生在客户端，所以客户的浏览器实现防御才比较容易。
于是有了同源策略 SOP ，注意，SOP 不阻止请求发出，但是可以阻止带着 Cookie 。还有非同源页面能否读网站响应。

你会发现请求不带 Cookie, 同时脚本不能跨源读数据，
上面说的两种攻击基本上就被阻断了。（当然实际情况更复杂些）
但是前后端分离也同样被阻断了。


你说的：
> "浏览器访问 a 网站时 a 网站的脚本访问 b 网站，无论是 post get 还是 options ，是否响应是 b 网站自身逻辑说的算的，即便 Access-Control-Allow-Origin:* 也只是告诉浏览器 b 允许所有来源访问，至于如何响应是看代码。"


带上 SOP 以后，由 a 发起的访问 b 网站的请求不会带有 b 的 cookie ，响应也未必能被 a 的页面读取。敏感操作和敏感信息都 a 都搞不了。

而 Access-Control-Allow-Origin 是 CORS 的一部分，作为同源策略 SOP 的扩展，允许你提供接口的服务器指定哪个网站可信(可以发 cookie 和可以读响应)，就是告诉浏览器第三方网站的白名单，白名单里的网站应该不会让浏览器发恶意请求，可以让 SOP 信任。CORS 给开发部署提供一些灵活性。这样你又可以前后端分离了。

顺便，你设置成 Access-Control-Allow-Origin:*的时候，浏览器的 Cookie 是不会发出去的。这整套机制都是怕浏览器被第三方恶意网站利用。
至于调试工具，，你不用调试工具当日常浏览器，不用担心被钓鱼，而且 CORS 也要被调试。所以当然不遵守这些。

楼上有人说的 CSS 应该是 XSS. 那个是 CSP 机制的事情。因为恶意脚本插入正常网站后是同源的。

楼主感到疑惑：貌似只是告诉客户端一个白名单让客户端自觉连接，服务端是不是还要判断 @$%^&%
楼主可能知道这是什么，但是不知道这个目的是什么...我们从头来说吧

5 楼说了安全问题。是的。如果 A 网站能读取浏览器保存的 B 网站的 Cookie ，或者 A 网站的脚本能随意让浏览器对 B 网站发起请求(比如转账操作)，是不是不安全？

于是搞了一个同源策略。如果非同源，即便要求发 Ajax 也会拒绝。非同源就 0 信任。
但是这样的同源策略是否有些过于严格？

如果我前后端分离，我域名或者端口就是不一样怎么办？我前端就是需要加载别的域名的 API 怎么办？反正我就是要加载非同源的东西，你一个同源策略因为安全问题就把它堵死了？搞得 AJAX 用不了。

楼主说的 Access-Control-Allow-Origin 这就来了。
后端需要告诉浏览器，哪个前端网站你可以信任，在他的页面可以给我发请求，我们是一家的。

这是设置一种因为信任而可以设置安全例外的做法。

客户端不自觉？那是客户端有安全缺陷。你做网站的恐怕做不了太多。

@cmdOptionKana 我赞同你的说法。
我也认为，如果特别“厌蠢”，可能缺乏耐心和换位思考能力，对结果焦虑或者有别的心理/情绪障碍。
但是也正常，谈不上心理障碍。

但是我个人认为不是逆反心理。可能你在当时感到焦虑在大脑里留下负面印象后，你父亲问你的时候你会开始 panic
尤其是渴望得到父母肯定的阶段，小孩会因为自己的行为而感到懊恼，或者因为父母的批评/压迫感而焦虑。
这种焦虑多次出现以后就会建立一个非常负面的正反馈。
以后会在每次遇到同样的事情时，焦虑发作，开始占用很多意识资源，思考不了。
在家长看来，一提这个问题怎么这倒霉孩子就和我急？这是和我“对着干”？逆反？


另外，说说 教人教不会
就像很多老年人不会用电子产品，因为他们对这东西没兴趣。很多年轻人觉得理所当然的 UI 设计他们也看不懂。
我举个例子

比如德语，krankenversicherung ，法语，intergouvernementalisations
对于母语者记忆这些词是比较轻松的。但是如果你不是，而且你没有基础，无论教还是学，都很痛苦。

换个更容易理解的角度说，
比如“沐浴”的“沐”，
我相信在这里的中文母语者应该都在学了“什么是三点水”，“木”这两个东西以后再接触这个字的。你很容易学会这个字的读写含义。
但是，你找个分不清中文日文的外国人，你让他学，他会很痛苦。
在他眼里只是觉得这是一堆点和线堆砌的复杂恶心的结构(还有笔划顺序)，还要记怎么读，什么读音，什么意思.....


同样我也想这里吐槽我的某些老师，他们支持“你学习时间越长越好”“你背下来就行”
这些老师很努力，很痛苦，很愤怒，很困惑。“这孩子是不是蠢...？”
其实你也很努力，很痛苦，很愤怒，很困惑。“我是不是真蠢......”

不是所有人都有一样的“基础知识”

回到这个主题，我不认为这是心理障碍。每个人都在用自己的视角看问题，很正常。
但是你也的确应该用别人的视角看一下，看一下别人知道什么，这坑多深得填。
如果你觉得教的成本过高且没收益，就算了。不生气。

简而言之：
Charles 篡改了通信内容，普通代理没有。
Charles 为了能抓包看明文，要破坏了加密，伪造证书搞中间人攻击。但是普通代理没在乎，看啥转啥。


不简而言之，说个场景：


A 和 B 要写信，这信都在盒子里送走，这盒子最好要上个锁，防着邮差。

于是 A 和 B 决定：

1. 正常通讯都用密码锁，安全还方便。
2. 所以，通讯之前，A 要把 密码锁的密码 发给 B 。然后他们就可以用密码锁和这个密码通信了。

问题是，这个送 密码锁的密码 的盒子，本身又该怎么确保安全？
3.于是，B 只能先把自己的，经过 ”权威机构认证的 B 专用锁” (B 的证书) 发过去，这锁的钥匙只有 B 他自己有。
4. 然后 A 收到后，就用 B 的锁，锁住里面是密码的盒子，发给 B 。
4. B 就可以用自己私人钥匙打开盒子，看到密码，接下来就可以也用 密码锁 锁住盒子来进行接下来的安全通信了。

Charles 和普通代理都是送盒子的邮差，但是有区别：
Charles 为了破坏加密，会在中途，把最开始 B 的锁换成自己配的锁，而自己则收下 B 的锁。这样，A 会用 Charles 的锁来锁盒子。A 想出的密码这下邮差 Charles 就能知道了。Charles 也可以假装 A 给 B 发一个自己编的密码。

Charles 可以对通信为所欲为，这样加密就完全被破坏了！

然而 A 发现 Charles 调包过的锁觉得不对劲，这锁也没经过权威机构认证啊，看起来绝对不是 B 的，我不接受！于是他停止了发信 (报个错)，B 也迟迟没收到来信所以这事情就没了下文。

(以上是过度简化且不准确的 TLS-RSA ，就不提 dhe 系列了。反正证书被换了就不该有下文。)


而普通代理该送啥就送啥。根本懒得看里面是啥，也压根没碰过。
管你是 https 还是 DNS ，还是什么锁，反正有东西我都送走就是了。

这里最大的区别就是：Charles 篡改了通信内容破坏加密，但是普通代理没有。


最后，你可以 root 后导入你 Charles 的证书到系统证书里。运气不好的话你可能遇到了 SSL Pin. 我之前用 Xposed 模块解决的这个问题。

1. 貌似天文那边抱怨过光学污染这事。
2. starlink 的确之前有和欧洲卫星和天宫潜在碰撞风险的事情。但是低轨道卫星报废后会坠毁进入大气层烧毁不会一直转圈。
3. 至于卫星相撞历史上发生过。的确要计算规避。
4. 碰撞概率并不是那么简单计算空间大小然后平均分布的...starlink 占用的低轨道基本都是一个半小时绕地球一圈。和它轨道交错的卫星又不是没有。这么一圈一圈几年下来难免会有碰撞可能。
上面有人说 6600 辆车才有多大空间，可是目前低轨道卫星有将近一万颗。

想一想，一万辆 1.5 小时不到就绕地球一圈的车，不少还路线互相交错。一年将近六千圈，每圈又和一些别的轨道交错。这五年十年下来难免...

有价值的轨道是有限的。starlink 这些年已经在越来越频繁变轨规避碰撞了，过去六个月进行了 5w 次规避机动。
顺便，根据各种发射计划，目前在轨卫星还远不算多。

另外说点轨道污染的问题。这么说吧：
Kessler syndrome: 在某个临界情况，比如可能会因为一次卫星碰撞产生上千个碎片，这些碎片可能击毁别的卫星而产生更多碎片，最终可能会是链式反应...

另外说回到楼主说的 DF31AG ，我不了解。猜测算过，不然麻烦比较大。另外如果 ICBM 被通讯卫星拦截这是否...