Web Security
The goal of this document is to help operational teams with creating secure web applications. All Mozilla sites and deployments are expected to follow the recommendations below. Use of these recommendations by the public is strongly encouraged.
The Security Assurance team maintains this document as a reference guide.
Table of Contents
Cheat Sheet
Transport Layer Security (TLS/SSL)
HTTPS
HTTP Strict Transport Security
HTTP Redirections
Resource Loading
Content Security Policy
contribute.json
Cross-origin Resource Sharing
CSRF Prevention
Referrer Policy
robots.txt
Subresource Integrity
X-Content-Type-Options
X-Frame-Options
Version History
Web Security Cheat Sheet
Guideline
Security
Benefit
Implementation
Difficulty
Order
Requirements
Notes
HTTPS
MAXIMUM
MEDIUM
Mandatory
Sites should use HTTPS (or other secure protocols) for all communications
Redirections from HTTP
MAXIMUM
LOW
Mandatory
Websites must redirect to HTTPS, API endpoints should disable HTTP entirely
Resource Loading
MAXIMUM
LOW
Mandatory for all websites
Both passive and active resources should be loaded through protocols using TLS, such as HTTPS
Strict Transport Security
HIGH
LOW
Mandatory for all websites
Minimum allowed time period of six months
TLS Configuration
MEDIUM
MEDIUM
Mandatory
Use the most secure Mozilla TLS configuration for your user base, typically
Intermediate
Content Security Policy
HIGH
HIGH
10
Mandatory for new websites
Recommended for existing websites
Disabling inline script is the greatest concern for CSP implementation
HIGH
MEDIUM
Mandatory for all new websites
Recommended for existing websites
All cookies must be set with the Secure flag, and set as restrictively as possible
contribute.json
LOW
LOW
Mandatory for all new Mozilla websites
Recommended for existing Mozilla sites
Mozilla sites should serve contribute.json and keep contact information up-to-date
Cross-origin Resource Sharing
HIGH
LOW
11
Mandatory
Origin sharing headers and files should not be present, except for specific use cases
Cross-site Request Forgery Tokenization
HIGH
UNKNOWN
Varies
Mandatory for websites that allow destructive changes
Unnecessary for all other websites
Most application frameworks have built-in CSRF tokenization to ease implementation
Referrer Policy
LOW
LOW
12
Recommended for all websites
Improves privacy for users, prevents the leaking of internal URLs via
Referer
header
robots.txt
LOW
LOW
14
Optional
Websites that implement robots.txt must use it only for noted purposes
Subresource Integrity
MEDIUM
MEDIUM
15
Recommended
Only for websites that load JavaScript or stylesheets from foreign origins
X-Content-Type-Options
LOW
LOW
Recommended for all websites
Websites should verify that they are setting the proper MIME types for all resources
X-Frame-Options
HIGH
LOW
Mandatory for all websites
Websites that don't use DENY or SAMEORIGIN must employ clickjacking defenses
Suggested order that administrators implement the web security guidelines. It is based on a combination of the security impact and the ease of implementation from an operational and developmental perspective.
Transport Layer Security (TLS/SSL)
Transport Layer Security provides assurances about the confidentiality, authentication, and integrity of all communications both inside and outside of Mozilla. To protect our users and networked systems, the support and use of encrypted communications using TLS is mandatory for all systems.
HTTPS
Websites or API endpoints that only communicate with modern browsers and systems should use the
Mozilla modern TLS configuration
Websites intended for general public consumption should use the
Mozilla intermediate TLS configuration
Websites that require backwards compatibility with extremely old browsers and operating systems may use the
Mozilla backwards compatible TLS configuration
. This is not recommended, and use of this compatibility level should be done only after consulting the security team for a risk assessment.
Compatibility
Configuration
Oldest compatible clients
Modern
Firefox 63, Android 10.0, Chrome 70, Edge 75, Java 11, OpenSSL 1.1.1, Opera 57, and Safari 12.1
Intermediate
Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, Safari 9
Backwards Compatible (Old)
Firefox 1, Android 2.3, Chrome 1, Edge 12, IE8 on Windows XP, Java 6, OpenSSL 0.9.8, Opera 5, and Safari 1
See Also
Mozilla Server Side TLS Guidelines
Mozilla Server Side TLS Configuration Generator
- generates software configurations for the three levels of compatibility
HTTP Strict Transport Security
HTTP Strict Transport Security (HSTS) is an HTTP header that notifies user agents to only connect to a given site over HTTPS, even if the scheme chosen was HTTP. Browsers that have had HSTS set for a given site will transparently upgrade all requests to HTTPS. HSTS also tells the browser to treat TLS and certificate-related errors more strictly by disabling the ability for users to bypass the error page.
The header consists of one mandatory parameter (
max-age
) and two optional parameters (
includeSubDomains
and
preload
), separated by semicolons.
Directives
max-age:
how long user agents will redirect to HTTPS, in seconds
includeSubDomains:
whether user agents should upgrade requests on subdomains
preload:
whether the site should be included in the
HSTS preload list
max-age
must be set to a minimum of six months (15768000), but longer periods such as two years (63072000) are recommended. Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached.
includeSubDomains
notifies the browser that all subdomains of the current origin should also be upgraded via HSTS. For example, setting
includeSubDomains
on
domain.example.com
will also set it on
host1.domain.example.com
and
host2.domain.example.com
. Extreme care is needed when setting the
includeSubDomains
flag, as it could disable sites on subdomains that don’t yet have HTTPS enabled.
preload
allows the website to be included in the
HSTS preload list
, upon submission. As a result, web browsers will do HTTPS upgrades to the site without ever having to receive the initial HSTS header. This prevents downgrade attacks upon first use and is recommended for all high risk websites. Note that being included in the HSTS preload list requires that
includeSubDomains
also be set.
Examples
# Only connect to this site via HTTPS for the two years (recommended)
Strict-Transport-Security: max-age
63072000
# Only connect to this site and subdomains via HTTPS for the next two years and also include in the preload list
Strict-Transport-Security: max-age
63072000
includeSubDomains
preload
See Also
MDN on HTTP Strict Transport Security
RFC6797: HTTP Strict Transport Security (HSTS)
HTTP Redirections
Websites may continue to listen on port 80 (HTTP) so that users do not get connection errors when typing a URL into their address bar, as browsers currently connect via HTTP for their initial request. Sites that listen on port 80 should only redirect to the same resource on HTTPS. Once the redirection has occurred,
HSTS
should ensure that all future attempts go to the site via HTTP are instead sent directly to the secure site. APIs or websites not intended for public consumption should disable the use of HTTP entirely.
Sites should avoid redirections from HTTP to HTTPS on a different host, as this prevents HSTS from being set. Instead, for example, first redirect from http://example.com/ to https://example.com/ and then in a second redirect, redirect from https://example.com/ to https://example.org/
Examples
# Redirect all incoming http requests to the same site and URI on https, using nginx
server
listen
80
return
301
$host$request_uri
# Redirect for site.example.org from http to https, using Apache
VirtualHost
*:80
ServerName
site.example.org
Redirect
permanent
/ https://site.example.org/
VirtualHost
Resource Loading
All resources — whether on the same origin or not — should be loaded over secure channels. Secure (HTTPS) websites that attempt to load active resources such as JavaScript insecurely will be blocked by browsers. As a result, users will experience degraded UIs and “mixed content” warnings. Attempts to load passive content (such as images) insecurely, although less risky, will still lead to degraded UIs and can allow active attackers to deface websites or phish users.
Despite the fact that modern browsers make it evident that websites are loading resources insecurely, these errors still occur with significant frequency. To prevent this from occurring, developers should verify that all resources are loaded securely prior to deployment.
Examples

src=
"https://code.jquery.com/jquery-1.12.0.min.js"
>

src=
"http://code.jquery.com/jquery-1.12.0.min.js"
>

src=
"http://very.badssl.com/image.jpg"
See Also
MDN on Mixed Content
Content Security Policy
Content Security Policy (CSP) is an HTTP header that allows site operators fine-grained control over where resources on their site can be loaded from. The use of this header is the best method to prevent cross-site scripting (XSS) vulnerabilities. Due to the difficulty in retrofitting CSP into existing websites, CSP is mandatory for all new websites and is strongly recommended for all existing high-risk sites.
The primary benefit of CSP comes from disabling the use of unsafe inline JavaScript. Inline JavaScript – either reflected or stored – means that improperly escaped user-inputs can generate code that is interpreted by the web browser as JavaScript. By using CSP to disable inline JavaScript, you can effectively eliminate almost all XSS attacks against your site.
Note that disabling inline JavaScript means that
all
JavaScript must be loaded from


src=
"https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"
integrity=
"sha384-r1y8TJcloKTvouxnYsi4PJAx+nHNr90ibsEn3zznzDzWBN9X3o3kbHLSgcIPtzAp"
crossorigin=
"anonymous"
>
# Generate the hash myself
curl
-s
openssl dgst
-sha384
-binary
openssl
base64
-A
r1y8TJcloKTvouxnYsi4PJAx+nHNr90ibsEn3zznzDzWBN9X3o3kbHLSgcIPtzAp
See Also
SRI Hash Generator
- generates