Configuring CORS in the Mendix Runtime
Introduction
Cross-Origin Resource Sharing (CORS) is a mechanism that allows a web application running on one domain to make requests to a server on a different domain. By default, browsers block such cross-origin requests for security reasons. If your Mendix front end is hosted on a different domain than the Mendix Runtime (for example, when using a separate single-page application or a microfrontend architecture), you need to configure CORS so the browser permits these requests.
This document describes the custom runtime settings required to enable CORS in the Mendix Runtime.
If you also enable CORS on a published REST service and configure Allowed Origins, access is granted to both the origins configured on the published REST service and the origins configured through the runtime settings described in this document.
Settings to Configure
To enable CORS, configure the following custom runtime settings. For general information on how to set custom runtime settings, see Runtime Customization.
Runtime Settings
| Name | Value | Description |
|---|---|---|
com.mendix.core.SameSiteCookies |
None |
Allows cookie sharing between the runtime origin and the client origin. This is required for cross-origin authentication to work correctly. The value needs to be set to "None", not left with no value. |
Custom HTTP Response Headers
In addition to the runtime settings above, you need to set the following custom HTTP response headers via the Headers setting:
| Header | Value | Description |
|---|---|---|
Access-Control-Allow-Credentials |
true |
Indicates that the server allows credentials (cookies, authorization headers) to be included in cross-origin requests. |
Access-Control-Allow-Headers |
Content-Type, x-csrf-token |
Specifies which HTTP headers can be used in the actual request. Expand this list if your application uses additional custom headers. |
Access-Control-Allow-Methods |
POST, GET, OPTIONS |
Specifies the HTTP methods allowed when accessing the resource. Expand this list if your application uses additional methods (for example, PUT or DELETE). |
Access-Control-Allow-Origin |
Your client domain (for example, https://my-app.example.com) |
The origin from which the client application is served. This must match the exact domain, including the scheme and port. |
Example m2ee.yaml Configuration
The following example shows how to configure CORS in an m2ee.yaml file. Replace YOUR_ORIGIN with the actual domain of your client application (for example, https://my-app.example.com):
mxruntime:
com.mendix.core.SameSiteCookies: None
Headers:
"Access-Control-Allow-Credentials": "true"
"Access-Control-Allow-Headers": "Content-Type, x-csrf-token"
"Access-Control-Allow-Methods": "POST, GET, OPTIONS"
"Access-Control-Allow-Origin": "YOUR_ORIGIN"Troubleshooting
If CORS is not working as expected, check the following:
- Browser console errors — Look for CORS-related error messages in the browser developer tools console. These typically indicate which header is missing or misconfigured.
- Origin mismatch — Ensure the value of
Access-Control-Allow-Originexactly matches the origin shown in the browser error, including the scheme (https://) and port number (if applicable). - Missing
SameSiteCookiessetting — Withoutcom.mendix.core.SameSiteCookiesset toNone, cookies will not be sent on cross-origin requests, which can cause authentication failures. - HTTPS requirement — When
SameSiteCookiesis set toNone, theSecureattribute is automatically added to cookies, meaning both the runtime and the client must be served over HTTPS.