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 ansrc=""
attribute. You may not use script attributes likeonclick=""
oronload=""
. You may not create<script>
tags dynamically and assign content to theirinnerHTML
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 theeval
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
andsetInterval
is banned -
You MUST pass callable objects (i.e.: functions) to the
setTimeout
andsetInterval
functions. Passing strings will not create the timer and the function will return0
. - Remote Web Workers are disallowed
-
If a
Worker
orSharedWorker
is created with a remote URL, it will behave as though the remote server responded with a400
error. - Script tags may not be created with remote URLs
-
If a
<script>
tag is created viadocument.createElement()
, setting itssrc
attribute to a remote URL will cause it to behave as though the remote server responded with a400
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>
andstyle=""
) are allowed, however, for privileged apps.
Certified App Restrictions
Certified apps are subject to additional restrictions.
- Inline styles are banned
-
<style>
andstyle=""
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()
ornew 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()
andhtml()
, 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 usepostMessage()
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=""
oronmouseover=""
, your code violates the CSP. You cannot set event attributes in a privileged packaged app. You should useaddEventListener()
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.