您的服务器颁发的 API 密钥具有与其关联的 CORS 来源。 当服务器收到API请求时，它会从自定义标头中发送的API密钥中检索CORS来源并进行CORS判断。 由于预检请求时未发送自定义标头（API key），无法进行 CORS 判断。
作为解决方案，我们正在考虑允许任何来源，在预检请求时不进行 CORS 判断，并在后续 GET 和 POST 请求时根据与 API key 关联的 CORS 来源进行判断。 有安全问题吗？
预检请求的存在是为了防止 CORS 之前的 Web 应用程序因 CORS 的出现而变得脆弱。
即使没有预检请求，现代应用程序也可以通过检查 HTTP 请求中的 Origin 标头来阻止应用程序端未经授权的请求。
但是，CORS 之前的应用程序没有实现此类安全功能。
危险请求启用的主要攻击媒介是跨站请求伪造 (CSRF)。虽然通过 POST 请求的 CSRF 甚至在 CORS 之前就应该得到缓解，但使用 PUT 或 DELETE 等方法的端点在 CORS 之前没有已知的攻击向量。因此，使用 PUT 或 DELETE 的端点有可能未实施 CSRF 对策。
简单请求与预检请求密切相关，对应于可以通过 HTML 表单发送的请求。如果没有 CORS，则无法发送其他请求。因此，预检请求的存在是为了涵盖开发人员可能认为“此端点需要 PUT 方法。PUT 方法无法使用 HTML 表单发送。因此，此端点不需要 CSRF 保护。”的情况。
因此，对于新开发的 API 端点，预检请求的保护并不是必需的，可以在 GET 和 POST 端点主体本身上实施对策。
但是，真的有必要允许所有来源的预检请求吗？