Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Cross Origin Policies for Webassembly

A topic by eri0o created Oct 23, 2020 Views: 562 Replies: 17
Viewing posts 1 to 7
(1 edit) (+2)


Currently Firefox requires two additional headers being served when loading webassembly code:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

These headers are soon going to be required in Chrome too:

Are they enabled in when serving HTML5 games?  This is required when using webworkers, which are very useful for threading in games, like for Audio and other usages.

A note, this is not mentioned in the documentation here:

It would be useful whatever is the case to mention this on the documentation.

Yesterday I uploaded multiple games that can not be played in Firefox because these headers are missing. It would be a shame if they soon can't be played in Chrome either. If possible, please add these headers!


Do you mind sending me an example page of a broken game so I can take a closer look? It can be draft or restricted. Thanks


An example game would be SNAKE SNAKE SNAKE.

In Chrome it will work just fine, in Firefox you will get the following error: Uncaught ReferenceError: SharedArrayBuffer is not defined

This is a LÖVE game that has been ported with Love.js.


Thanks, I updated CDN config and from what I can tell things are working as intended, could you go ahead and check as well?

(2 edits) (+1)

Hmm no it doesn't run on Firefox for me. I still get the error "Uncaught ReferenceError: SharedArrayBuffer is not defined". Does it work for you?

Edit: I should probably check if the game works on a website if it has those headers. I will test that out.

Edit 2: I hosted it on my website with the following in my .htaccess and it works

Header set Cross-Origin-Opener-Policy: same-origin
Header set Cross-Origin-Embedder-Policy: require-corp

Admin (1 edit) (+1)

Thanks for testing. I was only testing by loading the iframe contents directly, but it looks like the entire chain of embedding pages will need have their headers updated.

I’ve identified some breaking issues with these headers for existing games though, so I’ve decided to turn off these headers for now.

It looks like we’ll probably have run two separate CDN configurations at the same time to ensure maximum compatibility. Our backend storage does not let use set headers per object, so these headers will have to be globally injected at the CDN. So I’ll likely have a Legacy mode and a New mode for when you choose how your HTML5 games are delivered.

(1 edit) (+1)

Just wanted to pop in and say I am having the same exact issue running a LOVE2D game in Firefox that was transpiled via Love.js.

EDIT: In case it's useful, here is the game where I am having the same issue (loads fine in Chrome and Chromium browsers but not Firefox/Safari) -


Can you provide a link to an uploaded game that experiences this problem so I can take a closer look.

We’ll likely have to rely on a standardized file extension to be able to automatically apply these headers when extracting games.

for the standardized file I would suggest something like an empty .coopcoep file, or alternatively a yaml file for defining headers. Netilify has the following:

A note, at current time, it appears that Netilify also doesn't support such specific headers - so investigate them before implementing. 

Admin (1 edit) (+2)

Giving people directly control over headers is a security risk so I would prefer to have a something a bit more strict. Additionally, we have a lot of newer (and tired!) game devs uploading HTML5 games. I don’t want to push them into writing configuration files because it’s going to result in broken games, confusion & support tickets. Ideally something that transparently works.

On closer inspection I see that the document hosting the game must include those headers, and not the WASM code itself. I think that it’s probably safe to just apply those headers to all index.html files extracted for HTML5 games.


awesome! That will work :)

I can't, I ported Adventure Game Studio runtime for Webassembly, currently I have two versions, one using single thread, and one multithread using workers. I plan to use the single thread version since it doesn't require these headers.

The port was done using Emscripten. The SharedBufferArray restriction is documented in the previously provided links and it's the memory area used for communication between threads (workers).

This is due to pthreads implementation on Emscripten, detailed here:

The headers are unfortunately a requirement when using Emscripten pthread implementation.


I’ve deployed updated CDN configuration that should resolve this issue. Could you please test this and confirm that things are working as expected.

(Also spotted a bug that was preventing gzip from happening on some assets)


I had to roll back these changes, it was breaking backwards compatibility for some games. I’ll have to explore a different solution.

(3 edits)

Hi, I recently uploaded this twine game to itch -
none of the assets load. When I take a look at the headers in the network tab, I see that the cross origin resource policy is not set. How do I get around this?

Admin (1 edit) (+1)


I see that images used in your game are being blocked, it’s due to you referencing images hosted on another platform. I strongly recommend that you include all resources, like images, directly in your game’s zip file. If you need to include external resources then you will need to host them somewhere where you can modify the headers to allow that asset to be included.

Hope that helps

This topic has been auto-archived and can no longer be posted in because there haven't been any posts in a while.