> On Mar 9, 2023, at 11:00 AM, Jaimandeep Singh > <jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote: > > Dear All, > > IMO it is not recommended to add this section because of the following: > (a) It is a very specific use case for SPAs or similar design approach and > does not warrant mentioning the same in the security BPC as it is further > likely to complicate and misrepresent the issue at hand. > > (b) It's difficult to appreciate and confusing why CORS SHOULD/MAY be enabled > for some endpoints and not recommended for others.
The simplest answer is that if it is a user interaction endpoint which may leverage browser-integrated state mechanisms (cookies, local storage), then CORS SHOULD NOT be enabled for security reasons. SHOULD guidance means they still can, but they should have justification for doing so. I can say from previously investigating the delta for making a pre-existing authorization endpoint CORS-safe that I believe it would be very challenging to do safely. For API endpoints which take and return requests without using browser-integrated state mechanisms, CORS enables a class of client usage. Disabling CORS only provides security benefits in that it (somewhat accidentally) deters user-bridged network introspection. There is effort incubated in the W3C to provide explicit protections for this scenario. I don’t think any of these guiding rules are OAuth specific - instead, I think the industry has done a terrible job explaining CORS to developers and to integrators. > (c) It is not appropriate for the BCP, particularly on security matters, to > endorse or propose an approach that could compromise security standards. The section is server security guidance based on the current state of browsers (which are the only clients which care about or respect CORS). The vast majority of OAuth interactions involve a browser user agent in some capacity. I would expect the Security BCP to be _the_ place to give guidance. > (d) The SPA pattern can be well supported by other mechanisms such as > enabling CORS at proxy level if required by the oauth service providers. Exactly. Setting or unsetting CORS does not restrict SPAs from being possible, as they can leverage BFF-style proxies to ignore CORS-based API restrictions, or even pure reverse proxies for the token endpoint that hand the access and refresh token back to javascript. Leaving CORS disabled on public-facing server API provides no server security benefit in itself, it just artificially and ineffectually restricts a class of clients. I think we do the industry a disservice by not explaining the security and interoperability value to implementers/integrators, which is why I think such a section is justified - it is certainly a case where people may commonly deviate from best current practice. The actual guidance is an orthogonal issue. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
