Since I'm thinking about it, and while it's a little informal (I wrote this as a blog for an internal audience), here's some detail on CORS headers specifically that I like to send to folks to help provide context:
CORS and ArcGIS Enterprise
I frequently have the opportunity to review and comment on automated security scans organizations perform against their ArcGIS Enterprise instances. A point of confusion I see is regarding 'Insecure CORS Configuration', which some tools flag as a 'HIGH' priority finding.
In general, context is key when examining security related findings, and a 'finding' is relative to the intent of the application.
Background:
CORS (Cross Origin Resource Sharing) is used in *JavaScript* applications when making POST requests to Feature of GP Services on a different server. CORS is not the only way to make cross domain requests. If a web application is just used for viewing a map service, CORS isn't used.
In context, CORS requests are used when editing feature services or submitting a job to a GP Service. CORS is enforced either at the client tier or via the web browser.
By Cross-Origin, what is meant is that if a web service and a web application are hosted on the same machine, no Origin Crossing happens.
If a web service is hosted on machine A and a JavaScript web application that consumes a service is on machine B (Crossing Origins), and clients interact with a Feature Service/GP Service via Post requests, machine B's FQDN must be configured in machine A's 'Allowed Origins'.
Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense-in-depth strategy.
By default ArcGIS Server and Portal for ArcGIS sets the Access-Control-Allow-Origin header to '*' (allowing all origins), because by default ArcGIS has no way of knowing from which domain web services will be consumed prior to installation.
This default configuration is what the automated tool flags.
Detail:
In many use cases (let's use Facebook as an example), there will be only one application consuming web services - Facebook.com. In this case, it makes sense to limit allowed origins to one domain - Facebook.com. However, if an Esri customer wants to configure Allowed Origins, the admin must know from where a given web app will be hosted. In many cases, this will be easy. Other times, it may not be possible to know from which domain an app that consumes services may be hosted. This all depends on the intent of the web service.
With ArcGIS Server, domains must be explicitly specified in a comma separated list. Wildcards are not supported. Best form is to use the FQDN format, like https://host.domain.com.
Starting at 10.6, we introduced the ability to set CORS origins in Portal for ArcGIS via the Portal Home Application. At previous versions, allowed origins can be set in the Portal Sharing API.
Allowed CORS origins can also be defined at the web tier. See: https://enable-cors.org – be careful though, if the same allowed origin is defined twice, the app may decline to consume the web service.
In Portal's case, CORS allowed origins applies to Portal items or resources instead of GIS Services. Wildcards are supported Portal-side.
TL;DR:
Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense in depth strategy that restricts how JS apps interact with web services depending on the origin of the request.
Proper context and framing is required to verify the severity of a given finding discovered by an automated scanner.