By default, the Media Server is designed for broad compatibility with third-party integrations and embedded clients. However, allowing cross-origin requests requires careful configuration to balance security and functionality.

Security Settings and Default Behaviors

When configuring the Media Server, it helps to understand how two distinct settings interact to protect your system:

• supportedOrigins (Controls Access-Control-Allow-Origin): Dictates which external domains are allowed to talk to the server. This remains * (wildcard) by default.

• supportedOriginCredentials (Controls Access-Control-Allow-Credentials): Dictates whether those external domains can read browser cookies or session data. This is set to false by default starting in version 6.1.2.

The Two Security Profiles

• Standard (Default): Permissive origin matching (*), but strict credential handling (false in 6.1.2+). Integrations like Maps, AI Managers, and community dashboards will work out of the box, but browser-based scripts cannot leverage session cookies maliciously.

• High (Strict): Restrictive origin matching. The server is forced to validate the Origin header rigidly. This provides maximum isolation but is a breaking change for many third-party tools.

Compatibility Considerations

Before forcing the High security level or manually changing supportedOrigins to null:

• Authentication Migration Required: Because Access-Control-Allow-Credentials is now false by default in 6.1.2+, any browser integrations using cookie-based authentication on cross-origin requests (e.g., fetch with credentials: 'include', XHR.withCredentials = true, or Axios equivalents) will fail. They must migrate to header-based authentication: Authorization: Bearer <token>.

• Audit Integrations: Forcing strict origins (null) will block web-based dashboards or embedded clients calling the API from a different domain.

• Test in Staging: Ensure legitimate cross-origin requests are not broken before applying these settings to production environments.

New Installations

You can still enforce strict CORS protection during the initial setup wizard by choosing the High security profile in the Advanced Settings.

• Via WebAdmin: During "Setup New Site," select Advanced Site Settings and set the Security level dropdown to High.

• Via Desktop Client: In the "Get Started" dialog, select Advanced system settings and set the Security Level to High.

Existing Installations: Advanced Hardening

If you are running a version older than 6.1.2, or if you want to apply maximum origin hardening to a 6.1.2+ system, you can manually toggle the supportedOrigins setting to null.

WebAdmin Method

1. Navigate to the hidden Advanced settings of the WebAdmin via:

   https://<serverIp>:7001/#/settings/advanced

2. Scroll down until you find the HTTP header: Origin supportedOrigins setting.

3. Enter null to Enable Strict CORS Validation, or * to keep standard behavior.

Enabled Strict CORS Validation:

Disabled Strict CORS Validation:

REST API Method

To update the setting programmatically, send a PATCH request to the site settings endpoint.

NOTE: Before sending this request, you must obtain a fresh bearer token by authenticating via the /rest/v4/login/sessions endpoint.

1. Enable Strict CORS Validation (Hardening)

{
  "supportedOrigins": "null"
}

2. Revert to Standard Behavior (Wildcard)

{
  "supportedOrigins": "*"
}

Verification

To verify how your server is handling cross-origin traffic:

1. Open your browser's Developer Tools (F12 or Ctrl+Shift+I) and select the Network tab.

2. Navigate to or refresh your WebAdmin page.

3. Click on a primary network request (such as index.html) and inspect the Headers sub-tab.

4. Locate the Response Headers section to verify your profile:

   • Standard / Default Profile: Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: false

   • High / Hardened Profile: Access-Control-Allow-Origin: null

CORS validation disabled:

CORS validation enabled: