HLS playback broken from browser when origin differs from HLS server

[shargon]

Question

Description

When a browser application is served from a different origin than the MediaMTX
HLS server (e.g. app on localhost:7010, MediaMTX on localhost:8888), HLS
playback is impossible regardless of the client configuration.

MediaMTX unconditionally performs a session cookie-check for every HLS client.
This creates an unsolvable conflict with the browser CORS specification:

• Without withCredentials: true on the XHR, the browser does not send cookies
  → the cookie-check fails with:
  "HLS on iOS requires the server to set and read cookies"

• With withCredentials: true, the browser requires the server to respond with
  Access-Control-Allow-Credentials: true. MediaMTX does not include this
  header even when hlsAllowOrigins is set to the exact requesting origin.

Steps to reproduce

1. Start MediaMTX with: hlsAllowOrigins: ["http://localhost:7010"]
2. Serve a web application from http://localhost:7010.
3. Use hls.js with withCredentials: true to load any HLS stream from
   http://localhost:8888/{path}/index.m3u8.
4. Observe the browser console error:

Access to XMLHttpRequest at 'http://localhost:8888/.../index.m3u8' from origin 'http://localhost:7010' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'.

Expected behaviour

When hlsAllowOrigins is set to a specific origin (not *), MediaMTX should
also emit Access-Control-Allow-Credentials: true so that browsers can complete
credentialed requests required by the cookie-check flow.

Actual behaviour

Access-Control-Allow-Credentials is never emitted by the HLS server,
making cross-origin HLS playback from a browser impossible whenever the
cookie-check is active.

Question / Request

Is there a configuration option to:

1. Emit Access-Control-Allow-Credentials: true alongside a specific
   hlsAllowOrigins value?

2. Or disable the cookie-check entirely for environments where the application
   handles authentication via other means (e.g. JWT in the query string)?

Environment

• MediaMTX version: latest
• Browser: Chrome / Firefox (Windows)
• Client library: hls.js 1.5.15

---

Version: MediaMTX v1.20.0, windows, amd64

[yudin-s]

There are two separate cases here.

For hls.js in Chrome/Firefox/etc, you normally should not set withCredentials: true. Leave credentials off and set hlsAllowOrigins to the exact frontend origin. In the HLS server flow, MediaMTX first tries the cookie check and, for non-iOS clients that do not return the cookie, falls back to putting the session key in the playlist URL query. That path does not require Access-Control-Allow-Credentials.

So for a browser using hls.js, try:

const hls = new Hls({
  // no xhrSetup with withCredentials=true
});

and in MediaMTX:

hlsAllowOrigins:
  - https://your-frontend.example

The error text about "HLS on iOS requires..." is specifically the iOS/native-HLS branch, because native iOS HLS needs the cookie check to work. MediaMTX currently sets Access-Control-Allow-Origin, but I do not see a config option that also emits Access-Control-Allow-Credentials: true, so cross-origin native iOS HLS with cookies is the hard case.

For iOS/Safari native HLS, the practical workaround is to serve the player and HLS endpoint from the same origin, usually through a reverse proxy. For hls.js-capable browsers, keep credentials disabled and let the non-iOS query-token fallback handle the session.

If this matches what you are seeing, please mark the answer so the credentialed-CORS vs hls.js distinction is visible.

[aler9]

Hello, we were forced to remove Access-Control-Allow-Credentials because resulting cookies were shared among every domain listed in hlsAllowOrigins and every page in the domain, and this was interpreted as a security flaw.

When performing cross-origin requests with XHR or fetch(), browsers do not offer a way to partition cookies by origin domain and target domain at the same time - cookies are partitioned by target domain only, so they are always shared regardless of the origin. This problem is not present when loading resources with I-frames, since they introduced CHIPS, that perform the proper cookie partitioning and that we support.

Therefore:

• If you do not need to support iPhone Safari, use hls.js, remove withCredentials: true and the fallback session mechanism will kick in. This is query-based, the session key is stored in the origin page and is not shared with any other page or domain.
• If you do need to support iPhone Safari, my advice is to use the iframe method.

[shargon]

but without credentials true I reveive the error:

{
    "status": "error",
    "error": "HLS on iOS requires the server to set and read cookies"
}

or

{"status":"error","error":"authentication error"}

using the url:

http://localhost:8888/01a009b7-e4a8-cece-2767-131174078574/index.m3u8?cookieCheck=1&token=MY_TOKEN_JWT

[aler9]

Using HLS URLs inside video tags is something that we never officially supported in the first place. Use one of the integration methods described in the documentation.

[RedShift1]

I fixed this by having my frontend proxy inject the Access-Control-Allow-Credentials header. Apache httpd config:

Header set Access-Control-Allow-Credentials true