简体繁体 English

CORS 是否应该知道预检响应的端点方法？

[英]Should CORS be aware of endpoints method on preflight response?

原文 2022-12-15 20:41:17 5 1 php/ symfony/ cors/ websecurity/ nelmiocorsbundle

I have a REST API backed with Symfony 4.3 and NelmioCorsBundle for the CORS.我有一个由 Symfony 4.3 和 NelmioCorsBundle 支持的 REST API，用于 CORS。 I would like to understand if by definition/best practice, it's correct that my security team requires me to respond OPTIONS requests indicating methods list ( Access-Control-Allow-Methods ) only with the methods that actually are meant to be used with the particular requested endpoint, instead of a complete list that are used by my entire API.我想了解根据定义/最佳实践，我的安全团队要求我仅使用实际用于特定方法的方法来响应指示方法列表 ( Access-Control-Allow-Methods ) 的OPTIONS请求是否正确请求的端点，而不是我的整个 API 使用的完整列表。

There's some documentation that clearly clarifies what is correct?有一些文档清楚地阐明了什么是正确的？ So that it is not subject to different interpretations about how.这样它就不会受到关于如何的不同解释。

The vast majority of tutorials and resources like MDN website, gives examples including all the methods ( GET , PUT , PATCH ...) but never clarifies that.绝大多数教程和资源，如 MDN 网站，都提供了包括所有方法（ GET 、 PUT 、 PATCH ...）的示例，但从未阐明这一点。 The NelmioCorsBundle doesn't give us any way to take from routes definition. NelmioCorsBundle 没有给我们任何方式来获取路由定义。 It's for single configuration only.它仅适用于单一配置。

1 个解决方案

The Fetch standard , which is the de facto specification for CORS, makes no prescription about this: Fetch standard是 CORS 的实际规范，对此没有规定：

Ultimately server developers have a lot of freedom in how they handle HTTP responses and these tactics can differ between the response to the CORS-preflight request and the CORS request that follows it [...]最终，服务器开发人员在处理 HTTP 响应的方式上有很大的自由度，并且这些策略在对 CORS 预检请求的响应和紧随其后的 CORS 请求之间可能会有所不同 [...]

In practice, different CORS middleware libraries do different things.实际上，不同的 CORS 中间件库做不同的事情。 Some (like rs/cors ) only reflect the one method, whereas others (like Express's CORS middleware ) always list all the allowed methods.有些（如rs/cors ）只反映一种方法，而其他（如Express 的 CORS 中间件）总是列出所有允许的方法。

You could argue that always listing all the methods allowed by your CORS configuration in the Access-Control-Allow-Methods response header is "safer":您可能会争辩说，始终在Access-Control-Allow-Methods响应标头中列出您的 CORS 配置允许的所有方法“更安全”：

On the one hand, you have to pay a small price in terms of bandwidth, because at most one of the methods listed in the Access-Control-Allow-Methods header is necessary for CORS preflight to succeed.一方面，您必须在带宽方面付出很小的代价，因为最多Access-Control-Allow-Methods标头中列出的方法之一是 CORS 预检成功所必需的。
On the other hand, it provides attackers no incentive to send additional probing requests meant to determine which methods your CORS configuration allows.另一方面，它不会为攻击者提供发送额外探测请求的动机，这些请求旨在确定您的 CORS 配置允许哪些方法。

If you're worried about revealing too much about other endpoints, you should be able to apply different CORS configurations to different endpoints.如果您担心透露太多关于其他端点的信息，您应该能够将不同的 CORS 配置应用于不同的端点。