Security best practices for Firefox front-end engineers

This guide will help Firefox developers understand the security controls in place and avoid common pitfalls when developing for Firefox front-end.

Existing Security Controls

Sanitizing all strings that enter the DOM through innerHTML and friends.

For code running with chrome privileges, we sanitize all HTML fragments that are created for chrome-privileged documents. This includes all DOM APIs that takes a string and parses it into a DOM tree.

We use our built-in Sanitizer with the following flags:


The sanitizer removes all scripts (script tags, event handlers) and forms elements (form, input, keygen, option, optgroup, select, button, datalist). The canonical truth for the list of whitelisted elements is the source code.

The last flag ensures that developers spot the problems early and can avoid them within the development cycle, rather than after shipping.


Linter rules against unsanitized DOM interaction

The Security Assurance team is maintaining an ESLint rule that disallows unsafe uses of innerHTML and similar DOM APIs. The linter makes an exception for code that uses string literals that are hard coded in the source code, assuming benevolent developers. Developers are able to avoid tripping the rule by using escaping functions in combination with template strings like so:

bar.innerHTML = escapeHTML`<a href='${url}'>About</a>`;

In chrome privileged code, any kind of remaining scripts will still be removed by our sanitizer.


List of disallowed DOM APIs

  • innerHTML
  • outerHTML
  • insertAdjacentHTML()
  • createContextualFragment()
  • document.write()
  • document.writeln()

Please take a look at the repository for an updated list

Document Tags and Contributors

Contributors to this page: freddyb
Last updated by: freddyb,