I would suggest SHOULD guidance for CORS for OAuth token endpoints and authorization endpoints which are publicly accessible.
There are a lot of misconceptions about the security properties of CORS, and in particular the security properties from disabling CORS for an otherwise safe resource. To my knowledge there is one benefit of disabling for solely internally-facing infrastructure. To detail, a public website interacting with a user agent bridging public and private networks can use IPs and DNS to attempt to scan internal web infrastructure. It may attempt to manipulate browser-accessible resources via GET/POST, and get some information on the shape of the network via error and timing-based analysis. Enabling or disabling CORS does not affect reachability for GET/form POST requests (which do not require CORS preflight), but does affect visibility of the response. In such an environment, having CORS enabled for a metadata resource might reveal additional information to an attacker - such as purpose of a particular system, and possibly the author/vendor of a particular product. Note that they may be able to get this from other heuristics of that product as well, through analysis of other GET/POST requests (such as to vendor-specific endpoints). There is an incubated effort ( https://wicg.github.io/local-network-access/ ) which has rather good introductory/explainer text for this class of issue. I believe Chrome has partially implemented (targeting roll out in 113) - I do not know other browser intention or status. As currently documented, this would effectively block API access across public and internal/private network ranges without a CORS pre-flight and a new pre-flight response. If adopted by other browsers, this provides a stronger ability to give SHOULD guidance for CORS, without distinctions between public and internal/private infrastructure. -DW > On Mar 8, 2023, at 8:36 AM, Aaron Parecki > <aaron=40parecki....@dmarc.ietf.org> wrote: > > Since that is my comment referenced in the OpenID thread, I should clarify > that my intent was to have this language in the Security BCP with the caveat > that it's only applicable if your AS intends on supporting SPAs. In other > words, we're not saying all ASs SHOULD add CORS headers, only ASs that intend > on supporting SPAs. However, even if the AS does not intend on supporting > SPAs, it still MUST NOT enable CORS at the authorization endpoint. > > I don't know the best language to put in front of Mike's suggested text to > make that clear, so suggestions are welcome. > > Aaron > > > On Tue, Mar 7, 2023 at 11:16 PM Mike Jones > <Michael.Jones=40microsoft....@dmarc.ietf.org > <mailto:40microsoft....@dmarc.ietf.org>> wrote: >> I propose adding the following section to the OAuth Security BCP >> specification: >> >> >> >> Usage of CORS >> >> >> >> The Token Endpoint, >> >> Authorization Server Metadata Endpoint, >> >> <spanx style="verb">jwks_uri</spanx> Endpoint, >> >> Dynamic Client Registration Endpoint, >> >> and any other endpoints directly accessed by Clients >> >> SHOULD support the use of >> >> <xref target="CORS">Cross-Origin Resource Sharing (CORS)</xref> >> >> to enable JavaScript Clients and other browser-based Clients >> to access them. >> >> CORS MUST NOT be used at the Authorization Endpoint >> >> as it is redirected to by the client and not directly accessed. >> >> >> >> >> >> Relevant background information can be found at >> https://bitbucket.org/openid/connect/issues/980 and >> https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at. >> >> >> >> -- Mike >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
