This is an archived page. It's not actively maintained.

Apps CSP

Unlike traditional web sites, privileged and certified apps enforce a CSP (content security policy) by default. This may cause quite a bit of existing code to break while porting and cause a significant amount of confusion if developers are unaware that the CSP exists. This article explains what the CSP restrictions are for apps

If a CSP is specified in the App Manifest, the specified CSP and the default CSP for the app's type will be merged. A specified CSP may not loosen restrictions of the default CSP. The Firefox Marketplace Validator detects violations of the CSP during the app submission process. This can be used to help find problems early in development.

How to apply a custom CSP to your app

See the App Manifest CSP section for instructions, and read the CSP policy directives page for a reference covering what can be included.

Applicable CSP Restrictions

Remote scripts are banned
You cannot point a <script> at a remote JavaScript file. This means that all JS files that you reference must be included in your app's package.
Inline scripts are banned
You cannot include scripts inline in your HTML. All <script> tags must have an src="" attribute. You may not use script attributes like onclick="" or onload="". You may not create <script> tags dynamically and assign content to their innerHTML property.
javascript: URIs are banned
URIs like <a href="javascript:alert('foo')"> will not execute.
eval is disallowed
You may not use the eval() function or the eval operator. Both will throw security errors.
The function constructor is banned
You may not use the Function() constructor. Using it will throw a security error.
Dynamic code execution with setTimeout and setInterval is banned
You MUST pass callable objects (i.e.: functions) to the setTimeout and setInterval functions. Passing strings will not create the timer and the function will return 0.
Remote Web Workers are disallowed
If a Worker or SharedWorker is created with a remote URL, it will behave as though the remote server responded with a 400 error.
Script tags may not be created with remote URLs
If a <script> tag is created via document.createElement(), setting its src attribute to a remote URL will cause it to behave as though the remote server responded with a 400 error.
Plugins are banned
The use of the <object> and <embed> tags is disallowed. Java, Unity, Silverlight, Flash, or Shockwave may not be used.
Remote styles are banned
All <link rel="stylesheet" href="..."> tags must link to files in your app's package. Inline style tags and attributes (<style> and style="") are allowed, however, for privileged apps.

Certified App Restrictions

Certified apps are subject to additional restrictions.

Inline styles are banned
<style> and style="" are both banned.

Default Policies

The default policies for apps are as follows:

Privileged CSP
default-src *; script-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'
Certified CSP
default-src *; script-src 'self'; object-src 'none'; style-src 'self'

Common Problems and Frequently Asked Questions

My privileged app is raising errors when I try to use jQuery.
If your app links to the jQuery CDN, your code violates the CSP. Make sure you include your copy of jQuery inside your package, and link to it with the src="" attribute on the script tag.
My templates aren't being rendered in my privileged packaged app.
If you're using a client-side templating library (such as Mustache or Nunjucks), you must ensure that you're precompiling your templates. This means that you must run a script to compile your templates from HTML to JavaScript before packaging your app. Privileged apps cannot use remote loaders that download and compile templates on the fly because the compiler uses eval() or new Function().
I set the CSP in my manifest to allow the use of [feature], but it still doesn't work.
You cannot loosen the default restrictions on privileged or certified packaged apps. The CSP field in the app manifest can only be used to tighten the CSP, not loosen it.
When I use certain jQuery methods, they don't work as expected. Why?
Some jQuery methods--such as those that load JSON-P and remote HTML--can violate the CSP. Code loaded via JSON-P injects a script tag onto the current page, which violates the CSP. You should use CORS-enabled APIs instead of JSON-P. jQuery will also try to download and execute remote scripts when using methods like load() and html(), which will also violate the CSP by creating <script> tags.
I need to run code that is loaded from an external domain, but can't because it's blocked by the CSP.
Try loading the code inside a remote or data:-URI <iframe> instead, and use postMessage() to send and receive messages to the script. Iframes that do not share your app's origin are not subject to the CSP.
Why don't my click or hover events fire?
If you're setting click or mouse event handlers with onclick="" or onmouseover="", your code violates the CSP. You cannot set event attributes in a privileged packaged app. You should use addEventListener() instead.
When I submit my packaged app to the Marketplace, I get a lot of CSP warnings. Why?
The Marketplace's validator tries to detect code which would otherwise violate the CSP. It produces these warnings whether your app is privileged or not. These are intended to help point out potential CSP violations to developers and Marketplace reviewers. In many cases, the CSP warnings are false positives, but can also provide useful feedback for improving your app's code. CSP violations sometimes indicate a lax coding style and can be used as a means of checking your work.

CSP warnings in the validator will NOT impact whether your app is accepted into the Marketplace. If your app is privileged and it does violate the CSP, however, you will be asked to fix this issue before your app is accepted.