假设跨域情景下的三个角色：用户（以及使用的浏览器），用户访问的网站 A ，网站 A 请求的网站 B 。
首先要明确，跨域规则究竟是在防谁，是为了解决什么问题？
用户访问网站 A ，或者用户访问网站 B ，网站与自身的互动都是同源的，被浏览器信任。
用户访问网站 A 时与网站 B 产生互动，用户可能并不知道会涉及网站 B ，网站 B 也不能信任来自其它前端的不可靠输入，这样的互动是浏览器所要阻止的。
所以，跨域规则是在防当前访问的网站 A 的恶意操作，保护用户与网站 B 之间的数据安全。
如果网站 B 允许网站 A 的跨域请求，那么实际上跨域保护的作用已经结束了。

再来看第一个问题，
> “我做为可能有恶意脚本的黑客……我的恶意 js……”
这里假定了网站 B 是恶意方，用户访问的网站 A 是正常的，但如果网站 A 都已经请求了恶意 js ，那网站 A 还是清白的吗？
OP 在 20L 举了一个 CDN 投毒攻击的例子，但你首先要想到，在 CDN 投毒之前，这一切是正常运作的，网站 A 请求了网站 B 的资源，网站 B 允许网站 A 的跨域请求。
后来其中某一方背叛了信任，虽然是不同源，但这根本不是跨域规则所要解决的问题，也就是需要禁止的跨域资源访问（非法请求访问合法资源），这直接就相当于是注入代码了。

第二个问题，
> “它咋知道我的请求带不带身份呢”
你没写过附带身份凭证的前端请求？你不明确附带身份凭证，那浏览器就不会发送附带身份凭证的请求。凭证是由浏览器管理的，你无法在前端代码中修改跨域请求附带的凭证 https://fetch.spec.whatwg.org/#forbidden-request-header
> “这个服务端必须是为什么要必须明确呢？如果不明确会怎么样呢？ ”
同样地，在跨域的语境下，你要搞清楚哪方是攻击方，哪方是受保护方（响应端、用户是被保护方，请求端是潜在的攻击方）。
不明确就说明后端根本没有考虑到可能有来自不明源的攻击，既然不遵循浏览器的安全规则，浏览器就当你是需要被保护的对象，禁止一切风险行为。