The defaults settings for the CORS filter provided in Progress Application Server for OpenEdge (PASOE) Web App are insecure and enable 'supportsCredentials' for all origins. 

 

CORS (Cross-Origin Resource Sharing) defines a mechanism to enable client-side cross-origin requests.

For any ABL WebApp, WEB-INF/oeablSecurity.properties reads by default: 
 

OECORSFilter.allowAll=true
OECORSFilter.allowDomains=
OECORSFilter.supportCredentials=true

This default configuration is insecure. ABL WebApp returns the following headers:

• Access-Control-Allow-Credentials: true
• Access-Control-Allow-Origin: copy of the Origin header from request

In this configuration any website can issue requests made with user credentials and read the responses to these requests.

This is expected behavior.

It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. 
Therefore, it is expected that most users will not be impacted by this issue.

The existing set of OpenEdge CORS defaults properties were built on the PASOE server's implementation and customer feedback about the types of applications they were developing and deploying.  The CORS default setting support a mixture of legacy clients, pure HTTP data services, HTML page sources for customer's web browser clients, and OpenEdge's JSDO for simplify data driven clients.  The direction was to apply security, but to also factor in seamless migration of WebSpeed HTML page generation type application, REST services, and JSDO clients for HTML 5 type applications. Which the defaults do by permitting the commonly recommended HTML page headers, methods, and supporting those stateful clients that employ server-side cookies for login context (which the majority do). That mixture of legacy ABL/Java/.NET clients and HTML type clients in a single application affects the AllowAll configuration.

Only the OpenEdge product developer knows what the mix of clients are based on their ABL application's implementation AND knowledge of their customer's requirements.  Therefore, our customers hold the responsibility for tuning the default CORS settings to their applicaiton's specific implementation and use of the PASOE server (minus the network aspect which is a ITOps determined configuration). We added CORS security with broader set of defaults knowingly without them being a costly burden for the majority of customers.  Then provide customers with certain requirements a pathway forward for optionally increasing that level of security based on their application and their customer's requirements.

One can point out the perceived flaws in the current set of defaults, but our current defaults are based on satisfying the bulk of our products and customers. They will stay that way until the information is available that shows our customers moving to different types of application architectures that are compatible with a tighter set of defaults.
 

Configure the CORS filter depending on your ABL WebApp requirements, rather than using the default configuration:

Allow non-CORS requests (generic)	Allow CORS requests	Allow CORS requests to protected resources	OECORSFilter configuration	Remarks
Yes	No	n/a	OECORSFilter.allowAll=true OECORSFilter.allowDomains=<dummy domain, eg the instance domain> OECORSFilter.supportCredentials=false	Add a non-empty string to OECORSFilter.allowDomains. For added security, set OECORSFilter.supportCredentials to false
Yes	Yes, from a restricted list of domains	No	OECORSFilter.allowAll=true OECORSFilter.allowDomains=<restricted list of domains> OECORSFilter.supportCredentials=false	CORS requests to public resources allowed  for a restricted list of domains (A comma-separated list of HTTP/HTTPS url names ).
Yes	Yes, from a restricted list of domains	Yes	OECORSFilter.allowAll=true OECORSFilter.allowDomains=< restricted list of domains> OECORSFilter.supportCredentials=true	CORS requests to public and protected resources allowed for a restricted list of domains (A comma-separated list of HTTP/HTTPS url names ).
Yes	Yes, from all domains	No	OECORSFilter.allowAll=true OECORSFilter.allowDomains= <empty>|* OECORSFilter.supportCredentials=false	No CORS restriction on public resources (anonymous user access)
Yes	Yes, from all domains	Yes	OECORSFilter.allowAll=true OECORSFilter.allowDomains=<empty>|* OECORSFilter.supportCredentials=true	Default insecure configuration. Vulnerable to exploit

References to Other Documentation:

“CORS Support.” OpenEdge 12 Documentation: Progress Application Server for OpenEdge: Administration Guide.
“CORS Flow Chart.” Tomcat 9 Documentation, Apache, tomcat.apache.org/tomcat-9.0-doc/images/cors-flowchart.png.