When the Access-Control-Allow-Headers is *, the Authorization header is not covered.

[vampirefrog]

Howdy, I'm getting this warning in the Firefox console when doing cross origin requests:

Cross-Origin Request Warning: The Same Origin Policy will disallow reading the remote resource at https://example.com/v1/version soon. (Reason: When the Access-Control-Allow-Headers is *, the Authorization header is not covered. To include the Authorization header, it must be explicitly listed in CORS header Access-Control-Allow-Headers).

Is there a way to get rid of it from the config xml, or should I report it as an issue or just wait for it to be fixed? Thanks!

[bchah]

This answer has more to do with security than the root issue you mentioned, but... If you are building an application that uses OME, I recommend not exposing the OME API to your end-users directly. Your application should provide its own API endpoint that filters results and only shows users what they are allowed to see based on permissions within the scope of your app. With uncontrolled access to the OME API users can potentially see or manipulate streams and other elements that they shouldn't be able to.

Here is some code from my app back-end which looks at the possible endpoints and restricts them to users based on the amount of damage they might be able to do. The request is passed to a call_ome_api() function which executes the API call internally to 0.0.0.0:{API-PORT}/{APPROVED-PATH}. This lets us keep OME much more secure by only allowing API calls from the localhost. And as a bonus, we get none of the CORS issues you are seeing in Firefox :)

I hope this inspires you to build a robust and secure API for your app!

$allowed_paths = array(
    "get_hosts" => "/v1/vhosts",
    "get_records" => "/v1/vhosts/default/apps/live:records",
    "start_record" => "/v1/vhosts/default/apps/live:startRecord",
    "stop_record" => "/v1/vhosts/default/apps/live:stopRecord",
    "get_global_stats" => "/v1/stats/current/vhosts/default",
    "get_stream_stats" => "/v1/stats/current/vhosts/default/apps/live/streams/",
    "get_stream" => "/v1/vhosts/default/apps/live/streams/",
    // This arg gets special attention
    // "get_my_streams" => "/v1/vhosts/default/apps/live/streams",
    "get_pushes" => "/v1/vhosts/default/apps/live:pushes",
    "start_push" => "/v1/vhosts/default/apps/live:startPush",
    "stop_push" => "/v1/vhosts/default/apps/live:stopPush",
    "disconnect_stream" => "/v1/vhosts/default/apps/live/streams/",
    "reload_certificate" => "/v1/vhosts:reloadAllCertificates",
);

$allowed_public_paths = array(
    "get_global_stats" => "/v1/stats/current/vhosts/default",
    "get_stream" => "/v1/vhosts/default/apps/live/streams/",
    "get_stream_stats" => "/v1/stats/current/vhosts/default/apps/live/streams/",
    "get_hosts" => "/v1/vhosts",
);

$allowed = false;
$internal_path = "/";
$method = "GET";
$data = null;

if (is("privileged") && array_key_exists($request["path"], $allowed_paths)) {
    enforcePrivileged();
    $allowed = true;
    $internal_path = $allowed_paths[$request["path"]];

    switch ($request["path"]) {
        case "get_stream":
        case "get_stream_stats":
        case "get_hosts":
        case "get_global_stats":
        case "get_records":
            $method = "GET";
            break;
        case "get_pushes": // Yes this is a POST, not a GET
        case "start_record":
        case "start_push":
        case "stop_record":
        case "stop_push":
            $method = "POST";
            break;
        case "reload_certificate":
            $method = "POST";
            enforceAdmin();
            break;
        case "disconnect_stream":
            $method = "DELETE";
            break;
        default:
            die("Invalid API call! No valid method for path: " . strip_tags($request["path"]) );
    }

} else if (loggedIn() && $request["path"] == "get_my_streams") {

    $allowed = true;
    $internal_path = "/v1/vhosts/default/apps/live/streams";
    $method = "GET";
    $result = json_decode(call_ome_api($method, $internal_path, $data), true);
    $streams = $result["response"];
    $my_channels = channelCheck();
    $matched_streams = array();
    // Check each string in the array to see if it matches a channel stream_key, else remove it
    foreach ($my_channels as $channel) {
        //try to find $channel["stream_key"] in the $streams string array
        $found = false;
        foreach ($streams as $stream) {
            if ($channel["stream_key"] == $stream) {
               array_push($matched_streams, $stream);
            }
        }
    }
    
    $result["response"] = $matched_streams;
    die(json_encode($result));
    
} else if ((!loggedIn() || !is("privileged") ||  isset($_SESSION["logged_in_as_public"])) && array_key_exists($request["path"], $allowed_public_paths)) {
    $allowed = true;
    $internal_path = $allowed_public_paths[$request["path"]];
    $method = "GET";

} else {
    logMe("Invalid Engine API call was made to: " . strip_tags($request["path"]) . " from " . $_SERVER["REMOTE_ADDR"]);
    die("Invalid API call - not logged in or incorrect path: " . strip_tags($request["path"]));
}

[vampirefrog]

Thanks for the response. I am not exposing the OME API to end users directly. I am just managing my own OME servers with this web UI, which I posted about here. I guess I should have been more clear, but let me try to explain better.

The client can access the OME API just fine, but the browser gives you a warning about the Access-Control-Allow-Headers header, and I figured, since everything else works just fine, this would just be an easy fix, to add Authorization explicitly to this header, and it would get rid of the warning in the browser (Firefox, haven't tried Chrome).

Below are the response headers for a random OME API request:

access-control-allow-credentials: true
access-control-allow-headers: *
access-control-allow-methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
access-control-allow-origin: *
content-type: application/json;charset=UTF-8
server: OvenMediaEngine
vary: Origin

The asterisk itself seems to be hard coded here:

response->SetHeader("Access-Control-Allow-Headers", "*");

however, I'm not sure what the proper value would be, to replace the asterisk. I am assuming Authorization would be sufficient? I am not sure what other headers are used besides Authorization.

Anyway, that was the point of my initial post, to request that someone take a look at this header and see if it's a good idea to replace the asterisk with something more specific so the browser doesn't complain.

Thanks!

[bchah]

Looks like the allow-headers can't be wildcarded if allow-credentials is set to true. Doesn't surprise me that only Firefox is enforcing that (or even just warning, not enforcing).

Seems like the solution is to explicitly list all of the allowed headers since "*" is not treated as a wildcard when you include credentials in the request. If that is true then technically it is only allowing a header of a literal asterisk. It could just be that relaxed enforcement from the browsers has prevented this from being noticed. I'm not sure how effective it will be for cross-origin since MDN also states this header gets stripped from redirects.

Anyhow, you can change the access-control-allow-headers value in OME > src > projects > modules > http > cors > cors_manager.cpp - give it a build and see if it changes things!

[bchah]

Here's an example of how you could change that code to assign it via an environment variable, to let you experiment further without building it every time (ACCESS_CONTROL_ALLOW_HEADERS_VALUE):

                // By default, set the Access-Control-Allow-Headers as wildcard
		ov::String allow_headers_string = "*";
		// Allow environment variable to set custom Allow-Headers header
		const char* allow_headers_env = std::getenv("ACCESS_CONTROL_ALLOW_HEADERS_VALUE");
		if (allow_headers_env != nullptr) 
		{
    	        allow_headers_string = allow_headers_env;
		}

		response->SetHeader("Access-Control-Allow-Headers", allow_headers_string);

[vampirefrog]

I've tried with

response->SetHeader("Access-Control-Allow-Headers", "Authorization,Content-type");

and it worked just fine. As far as a proper solution, it would be up to the maintainers to choose it, I was just reporting the issue.

Feel free to change this discussion into an issue.

[vampirefrog]

I've added Content-type to the list (for POST).