HTML5 Audio, Web Audio API, CORS and Firefox

Question

I have been trying to get this to run correctly so days now with no luck.

I have created a custom audio player, that accesses an MP3 on a S3 Amazon server. The audio player has custom controls enabled by Javascript, and a Audio Visualizer made possible by the Web Audio API.

Now the problem I am running into is this: Work fine on Chrome. Safari out right says it can't run the Web Audio API, but the audio will still play. In Firefox, the entire thing shuts down. Click play... nothing. I thought it was a CORS issue, so we set the proper headers on the server and still nothing. BUT... if I deactivate the Web Audio API visualizer, then I can get the player to play just fine.

http://jsfiddle.net/murphy1976/yqqf7uL1/1/

Here is my jFiddle. I have separated the Audio Player controls Script from the Visualizer Script with comments so you can see how it will work in Firefox, and how it will NOT work in Firefox.

I read somewhere that this issue that I'm running into MAY be a bug with Firefox. I just want to make sure so that I can stop beating my skull over this.

Could I put a call to CORS here?:

<source crossorigin="anonymous" src="audioFiles/35022797.mp3" id="srcMP3" type="audio/mp3">

Solution

The same-origin policy says that scripts run on some origin cannot read resources from another origin. (An origin is a domain, plus a scheme and port, like http://foo.example.com:80.)

Note that the same-origin policy does not prevent cross-origin media from being displayed to the user. Rather, it prevents scripts from programmatically reading cross-origin resources. Consider the <img> tag: a page on example.com can show a cross-origin image from other.com, but a script on example.com's page cannot read the contents of that image. The user can see it; the page cannot.

The Web Audio API can read the contents of audio files. If an audio file is from a different origin, this kind of reading is not allow by the same-origin policy. A user can listen to a cross-origin audio file, but a script on the page cannot read the contents of the file. When you attempt to feed a cross-origin audio file into an analyzer script (e.g., so that you can draw a visualization on a canvas), the same-origin policy should stop you. You are attempting to violate the same-origin policy, and the browser is correctly stopping you by refusing to play the audio in way that would allow you to read the file contents.

Note that Chrome does not prevent such cross-origin file reading for audio files, and this is incorrect behavior.

The correct solution is to have your media servers serve the audio files with a CORS Access-Control-Allow-Origin: * HTTP response header. However, this currently does not work in Firefox, which is incorrect behavior. If Firefox hopes to have a compliant implementation, this will be fixed eventually.

Comments

[Ian Lesperance]

As of Version 42, Chrome correctly blocks cross-origin file access using the Web Audio API. You can create a simple Audio object to play cross-origin audio, but you cannot create a MediaElementAudioSourceNode from that to, say, analyze the raw audio data.

[Anson Kao]

A good follow up on what your options are: stackoverflow.com/questions/30603872/…

[trusktr]

I understand your answer technically, but how is this a security concern? Or is it not about security? (I'm referring to reading contents of an MP3 files for example). Or is it about protecting other people's assets, and not about security?

[trusktr]

Also, even though I have the header set to "*" for a file from one domain, Chrome incorrectly continues to block me from reading the file on another domain. (It is an MP3 file). For example, see this conversation: twitter.com/CodePen/status/945810502399049728?s=09

[trusktr]

Is this a CORS bug in Chrome? bugs.chromium.org/p/chromium/issues/detail?id=798043 Or do I just not know what I'm doing?

[apsillers]

@truskr The simplest security example I can think of is: suppose you have an internet-enabled security camera on your home network, and it exposes past recordings to other devices on your network via a Web API. No website should be able to tell your computer's browser to load a recording from that camera's Web server and then read it with the Audio API and send it somewhere under the website's control.

[apsillers]

@trusktr I found this Q&A which suggests you need to include the property crossOrigin=true (or crossorigin=true?) in your <audio> element, just as you need to when reading <img> elements from a canvas.

[trusktr]

@aspillers I see, it's not that audio is insecure for the user's browser, it's about not letting any website (served from any domain) access content that is meant to be accessed only from sites from specific domains.