Of the more cryptic and frustrating Chrome errors are the SecurityErrors. These bad boys show up at inopportune times and ruin your day with an “Uncaught Error” and a big red exception killing your code in its tracks.
So you’re playing around with HTML5 Canvas when all of a sudden you’re getting a
Uncaught Error: SecurityError: DOM Exception 18 in the console. What’s it mean?
DOM Exception 18
This exception is thrown when your code is trying to access something it shouldn’t, including cross-domain resources or stuff on your local filesystem.
Once you hit this one you will either need to loosen your browser security settings which is never optimal, or find out how to work around it.
HTML5 Canvas & Exception 18
Which brings us to the case of the complaining canvas. Loading images into your canvas from another domain will “taint” your canvas, meaning any attempts to read the canvas back again will fail with this error.
Hypothetical Canvas Attack
For instance, if I hypothetically wanted to access your email and your browser didn’t prevent cross-site-scripting, I could perform a
$.ajax('http://gmail.com'). This would pull down your logged-in gmail page, and then I could send all your email messages back to my server.
The same applies for images.
This feature prevents a rogue site pulling down your Facebook photos, for instance (which again could hypothetically be done), rendering them to a canvas in order to get a hold of the binary image data then sending it back to the attack server.
So the second you draw a third party image to your canvas, you can no longer read back the resulting image.
The easy solution is to host all your images locally or if that’s not possible you could use a script to pull down and serve the images on your behalf.
SVG Image & Canvas SecurityError
If you’re playing around with drawing SVG to Canvas in Chrome, you may also run into this security error, but for a different reason.
This appears to be a Chrome-specific feature (perhaps a bug?) whereby the SVG document is considered to be of different origin to the canvas. This goes a step further than simply checking the origin of the url, it outright blacklists all SVG images regardless of origin, including images encoded in data: uris.
This means that whenever you paint a SVG to your canvas you’re tainting your canvas and won’t be able to pull information back out of it. This severely hinders efforts to use SVG images as dynamic game sprites, and can be frustrating to debug because it isn’t immediately obvious what’s happening.
Working around the same-origin policy
It’s actually possible to specify a custom policy to override the default same-origin behaviour. This is done via custom HTTP headers, which means you’ll need access to your web server to make these changes.
I haven’t yet experimented with this technique myself, but you can read about it on HTML5 Rocks. I’ll be playing with this in the following days, but if you’ve had luck with this technique, do let me know in the comments.