Security guidelines

Firefox OS Developer Guide

All Firefox OS apps use standard web technologies like HTML, JavaScript, CSS and SVG, but sensitive app permissions are restricted to privileged apps, which are delivered in a signed archive through the Firefox Market, rather than being deployed dynamically by an arbitrary web server. The purpose is to allow these apps to be reviewed from a security and quality perspective, to ensure they can be trusted with increased permissions levels. This section is intended to guide developers in writing secure packaged apps.

Use the following checklists to avoid the most common web application vulnerabilities. Each checklist is prefaced with a short discussion of the problem.

HTML/JavaScript/CSS injection and XSS

Injected code runs with the privilege of your app, and can potentially abuse any permission the app is granted. A default CSP policy is applied to all privileged apps, but this does not completely rule out this attack vector (note: in particular, inline styles are not yet prevented).

  • Where possible use .textContent instead of .innerHTML.
  • Use DOM functions (createElement/setAttribute) or a trusted template system.
  • Avoid string concatenation, especially for HTML attributes.
  • Declare stricter-than-default CSP, using the manifest's CSP directive.

Secure communication

While SSL is generally good practice for any website which sends and receives sensitive user data (password, private, credit cards etc.), unencrypted data transfer is even more critical on mobile devices, as they are more likely to be used on untrusted and potentially hostile networks.

  • Use SSL when sending sensitive user data across the network.
  • Be sure to use SSL when framing third-party content such as third-party oauth providers.

Web activities

Web activities provide a mechanism to send and receive data from other applications. When you start a web activity, there is no guarantee which app will handle it. If there are multiple activities which can fulfill your request, it is up to the user to choose, and vice-versa, when handling an activity. Any content, including untrusted web content, can initiate an activity, so therefore all input needs to be validated and sanitized.

  • Sanitation for handlers
    • Sanitize all input parameters.
    • Be careful what functionality you expose.
    • Any content can invoke your handler. Validate the origin of the caller if you only want to accept activities from specific apps.
  • Sanitation for callers
    • Validate return values from web activity handlers.
    • Consider that any app may handle your request.

Inter-app communication

All input to applications needs to be validated and sanitized. Mind that some input is not obvious, so some sources might be easily overlooked.

  • Validate the origin and content of message events.
  • Be careful with URLs (including location.hash). Although linking from one app:// to another is prevented, some forced-browsing scenarios are still possible. For example, if your application sets the location via user input.
  • Be careful handling any mozbrowser events from child frames (see Browser API section below).

Client-side storage

The risk of using client-side storage in privileged web apps is no different than in any web content. However, given that many privileged applications are designed to function without internet access, client-side storage will more likely be used for sensitive data.

  • Keep user data to a minimum and avoid storage of private user information where possible.
  • Provide users with a way to clear sensitive data.
  • Consider encryption prior to storage for particularly sensitive data. Mind that keys stored on the device can be recovered even after deletion.

Content Security Policy

Privileged apps have a default Content Security Policy (CSP) applied to them. Apps can be hardened by applying a more restrictive CSP policy which prevents loading external content. Note that even with a restrictive CSP policy in place, it is likely possible for the app to send data to the internet as data exfiltration is not preventable by CSP.

  • Consider applying a more restrictive CSP policy as a defence-in-depth technique.
  • In case of local-only content, apply: "csp": "default-src none; script-src self; image-src self;style-src self;"


The more permissions an app has, the greater the chance that those permissions might be abused in the case of a vulnerability. It is good practice to minimize permissions to only those APIs required by the application to function.

  • Only request the bare minimum of permissions necessary for your application to work.
  • Use access restrictions like read-only where the API supports them. See the access property in the table of permissions.

API-specific guidance

The corresponding permission names are given in parentheses.

Alarm API (alarms)
Alarm handlers should be short running. Running frequent alarms performing complex operations will drain battery life.
Audio Policy (audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm)
Use the channels for their intended purpose only. See Audio channels.
Especially, do not use the notification and alarm channels for longer periods of time. Do not use them to play music.
Browser API (browser)
Be careful when listening to mozbrowser* events. Validate and sanitize all parameters.
Ensure that mozbrowser is set on all untrusted content.
More here
Contacts (contacts)
Only request required access (API supports readonly, readwrite, readcreate, or createonly).
If readwrite access is needed, be especially careful not to delete or corrupt user contact data.
Consider keeping all your app's contacts separate from existing contacts by tagging them in some manner.
Notification API (desktop-notification)
Provide reasonable settings for the user to control notification frequency or disable notifications entirely.
Only request access needed (API supports readonly, readwrite, readcreate, or createonly).
Careful not to modify or delete user media (code checks into code to prevent global deletes etc.).
Abide by Mozilla privacy principles.
None, don't geolocate ;)
Provide user a way to enable and disable geolocation
Don’t keep log of geolocation without informing the user.
Provide mechanism to clear information.
Abide by Mozilla privacy principles.
Conduct checks to ensure that private networks are not accessed (if possible).
Conduct checks to ensure that private networks are not accessed (if possible).
Use TLS for sensitive data.

Firefox OS Reviewer Guide

This section is suposed to guide reviewers, be it developers or marketplace reviewers, to ensure consistent auditing for security controls. The two main goals of the review process are:

  • to apply the least privilege principle and minimize permission use.
  • to find security bugs.

HTML/JavaScript/CSS injection and XSS

For static apps, we only need to be concerned with DOM-based injection attacks and consider those JavaScript functions which result in changes to the HTML, CSS or scripts themselves. Below is a list of functions to audit.

JavaScript execution sinks

Note that all of these should actually be prevented by the default CSP policy, and as such should not be present in a privileged or certified web app. Included here for completeness mainly.

  • eval
  • setTimeout (with a string argument)
  • setInterval (with a string argument)
  • new Function
  • crypto.generateCRMFRequest (5th argument is eval'd)
  • .setAttribute("onXXX...", userinput) for setting event handlers (e.g. onmouseover, onclick, ..)
  • .addEventListener(evt, handler)for setting event handlers, like above
  • .onXXX= for setting event handlers, like above
  • document.createElement('script');

HTML element sinks

Dynamic creation of HTML elements. Note that script tags are prevent by CSP.

  • document.write
  • document.writeln
  • anyElement.innerHTML
  • anyElement.outerHTML
  • Range.createContextualFragment
  • parseFromString (DOMParser)
  • document.createElement might create "dangerous" tags as listed below.

Location sinks

Input used as part or all of a URL loaded by the app can be a risk. Check for JavaScript which:

  • assigns input to src, data, href, or action attributes on supported elements.
  • setting window.location, document.location etc.


  • Arbitrary injection into stylesheets, style elements, and inline styles
  • -moz-binding (input here)
  • url (input here)

Web Activities

  • Examine web activity handlers
  • Examine manifest to see activities registered
  • Examine the handler function for these activities. Search for mozSetMessageHandler('activity', …)
  • Examine initiation of Web Activities
  • new mozActivity(...)

Client Side Storage

Examine use of client-side storage mechanisms:

  • localStorage
  • indexedDB
  • sessionStorage
  • document.cookie
  • navigator.getDeviceStorage(...) - requires permission

Content Security Policy

  • Review custom Content Security Policy restrictions if they exist.
  • Consider suggesting a CSP for the app if one isn't already in place.
  • Recommend a strict policy for apps which don’t load any resources over the network.

Secure communication

  • Examine XHR requests, form posts, WebSockets. Ensure use of TLS.
  • If the app has TCPsocket permission, also examine this usage.

App layer Denial of Service

  • Insecure storage of sensitive data
  • App layer DoS (e.g. break an Gaia app, or the phone entirely, make a feature unusable - fill up the gallery with fake photos etc)
  • Does that app use encrypted channels (SSL)
  • Inclusion of third party content (framed or otherwise)
  • Communication with other frames or windows (e.g. onmessage handlers)

Inter-app communication

  • onmessage, addEventListener('message', ...) - Message handlers should validate the origin of messages.
  • postMessage - specify the target origin instead of using "*"
  • Web activities (see above)
  • mozBrowser events (see below)

Client-side storage

  • indexedDB
  • localStorage
  • sessionStorage
  • cookie

Other areas

  •, showModalDialog
  • mozSetMessageHandler(<name of message>,...) - Handles system messages like alarm, activity, notification, bluetooth-*, headset-button, ussd-recieved, sms-*, telephony-*, and icc-stkcommand.
  • Use of XMLHttpRequest - apart from ensuring data is sent over secure channels, ensure that response data is appropriately validated and sanitized.

Review the App Manifest

  • Ensure type is web or privileged
  • Review permissions requested for appropriateness. Consider allow restrictions.
  • Review system messages listened for.
  • Review activities handled.


Find unused permission and APIs used without the appropriate permissions. Regex collection to find privileged API use:

  • /mozAlarms/
  • /window\.open\s*\(\s*[\",\']attention/
  • /mozaudiochannel/
  • /mozBluetooth
  • /mozCameras/
  • /mozCellBroadcast/
  • /mozContacts/
  • /mozNotification/
  • /\.getDeviceStorage\s*\(\s*[\",\'](music|videos|pictures|sdcard|apps)/
  • /mozapp\/
  • /mozFMRadio/
  • /\.geolocation/
  • /\.addIdleObserver/
  • /mozMobileConnection/
  • /moznetworkupload/
  • /moznetworkdownload/
  • /mozPermissionSettings/
  • /mozPower/
  • /mozSettings/
  • /mozSms/
  • /mozSystem/
  • /mozTCPSocket/
  • /mozTelephony/
  • /mozTime/
  • /mozVoicemail/
  • /mozApps.mgmt/
  • /mozWifiManager/
  • /mozKeyboard/

Permission-specific recommendations

The sections below detail the standard use case for each API, what the potential threats related to an API are, and guidelines for reviewers for apps which intend to use these APIs.

Alarm API
Permission alarm
Use case Similar to setTimeout, except that the app is started if it isn't currently running. Used by apps for polling or other background processing. The intended use case is that the app can specify when it needs to be woken up to do processing.
Threats Firing frequent alarms to prevent an app from being shutown. Draining battery life or consume CPU time.
Review guidance

Look at alarm handler: Will it finish quickly? Does it do a lot of processing?

Audio Policy
Permissions audio-channel-normal, audio-channel-content, audio-channel-notification, audio-channel-alarm
Use case Competing with other audio channels, leave audio running when the user leaves the app (e.g. background music app). Note, the hierarchy of which channel gets preference: normal & content < notification < alarm < ringer < telephony < public notifications (iItalicized channels for certified apps only).
Threats Poorly designed or belligerent channels which block other sound from being played, blocking the notification or alarm channels for extended periods of time. Using the content channel for playing sounds that aren't expected to be played when the user isn't handling the app.
Review guidance Examine the use of audio channels.
Browser API
Permissions browser
Use case Act as a browser which allows the app to render web pages inside an iframe like it was a normal top-level browser frame.
Threats Bypass same origin, eg. using getScreenshot, not accurately displaying user location, insecure handling of mozbrowser events. Click-jacking of warning messages like untrusted certificate warning page.
Review guidance Examine use of mozbrowser frames - how and why are they used? Ensure that the app is not using the mozbrowser permission for malicious purposes. Make sure that the app does not blindly trust input parameters from mozbrowser events.
Contacts API
Permissions contacts
Use case Access the address book. There are read, write and create levels. Reviewers should review the app in line with the description.
Threats Scrape address book and send to third party server. Modify contents of address book without user consent.
Review guidance Should compare description to access requested.  If different, that should be flagged. Carefully review any code which changes contacts, especially functions which can be used to globally modify contacts.
Notification API
Permissions desktop-notification
Use case Send a notification that appears in the system tray. The user can click on the notification, and a event is sent to the application.
Threats Spamming the user, not providing controls to the user to limit notifications.
Review guidance  
Device Storage API
Permissions device-storage: pictures|videos|music|sdcard|app
Use case Access user media. Read, write, create access.
Threats Vandalize user media, unauthorized access
Review guidance Validate the requested access is what is being used.  Should only have the least access that is required to do what the app wants to accomplish. Do not allow global delete.
FM Radio API
Permissions fmradio
Use case Control the user, grantable to all apps.
Threats Power draining, privacy issues due to potential side-channel geolocation through FM band usage.
Review guidance Ensure app is not using API as a tracking mechanism (or if it does this, make sure it at least informs the user of this intent).
GEO Location API
Permission geolocation
Use case Obtain current user location
Threats Logging and storage of geolocation data
Review guidance Examine when geolocation will be prompted for (is it at an appropriate time). Examine what is done with geolocation data, is it stored, how frequently is it accessed etc.
Permission systemXHR
Use case Cross-origin XHR without CORS. Allows an app to request data from the web (without cookies or auth credentials).
Threats Requests to private address ranges, behind firewalls etc.
Review guidance  
TCP Socket API
Permission tcp-socket
Use case Opening a client socket to any host (for example e-mail or CalDAV), or creating a raw socket back to their server (although this should preferably be done with web-sockets).
Threats See systemXHR, internal address ranges, port scanning etc.
Review guidance  

Document Tags and Contributors

Contributors to this page: limewood, ptheriault, omerta, brandonyoungdale, Sheppy, crcr
Last updated by: limewood,