更准确的说法是“使用两个服务器，例如 api.myservice.org 和www.myservice.org 具有安全隐患”——换句话说，通常会被默认服务器 CORS 配置阻止。但是有一些安全可靠的方法可以通过调整这些设置来实现这一点。

将 URL 路径配置为指向不同主机的替代方法也具有安全隐患。由于 SEO 考虑（即您不希望搜索引擎索引您的 JS lib 文件），可以说支持您提出的方法。

在https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS阅读有关“跨源资源共享 (CORS)”的更多详细信息

从提供的信息来看，这绝对不是安全风险。只要在 API 端点（HTTPS、HSTS等）上设置了适当的控件，就可以开始了。

这里要注意的一件事是，它myservice.org可能在强化系统上运行并具有额外的保护（例如WAF）。在这种情况下，也必须应用这些控件api.myservice.org。

编辑：XSS 的论点在这里无关紧要，它不可能仅仅因为myservice.org和api.myservice.org被解耦而发生。

只有拒绝背后的人才能明确回答为什么他们认为这是一个安全问题。我发现以下问题对这样的讨论很有帮助（不一定是所有问题，因为其中几个问题很可能会被一个问题回答）：

1. 这是哪种类型的安全问题？“XSS”不足以作为答案，因为不清楚为什么会出现这种情况。
2. 这是由某人或某事（例如法规或利益相关者）强制执行的吗？如果组织维护的所有其他服务都以相同的方式工作，则可能被认为是不必要的复杂性。
3. 你有参考吗？与安全相关的文章通常是由一生从事安全工作的人撰写的，而那些可能已经阅读并同意该文章但不一定能清楚地证明他们的立场的人。当然，仅仅因为某个时候有人认为这是一个问题，仍然需要有人验证它是否真的与您相关，以及权衡是否值得。作为一个快速的对立面（当然，没有证据并不是没有证据），OWASP 前十名似乎没有在他们的XSS或CSP文章中明确提到子域是一个问题。

例如，如果 API 和 SPA 依赖于相同的 cookie 凭据，并且您没有完全控制最近的公共高级域，您可能会遇到问题。您必须在该更高级别的域上设置 cookie，如果攻击者获得对不同子域的访问权限，这可能会让攻击者窃取它们。首先不是一个很好的情况，但会让我考虑使用单个（子）域。

这只是一个例子（并且是一个相当容易避免的问题），但是你应该让那个喊“安全”的人提出一个理由，因为它可能是合理的。魔鬼在细节中，这里没有足够的细节来让一个自信的“没问题”恕我直言。

您可以为 API 使用不同的服务器和代码库，即使它只是位于同一域的不同路径下。