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
Public Key Pinning	Low	Maximum	--	Mandatory for maximum risk sites only	Not recommended for most sites
Redirections from HTTP	Maximum	Low	3	Mandatory	Websites must redirect to HTTPS, API endpoints should disable HTTP entirely
Resource Loading	Maximum	Low	2	Mandatory for all websites	Both passive and active resources should be loaded through protocols using TLS, such as HTTPS
Strict Transport Security	High	Low	4	Mandatory for all websites	Minimum allowed time period of six months
TLS Configuration	Medium	Medium	1	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
Cookies	High	Medium	7	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	9	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	6	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	8	Recommended for all websites	Websites should verify that they are setting the proper MIME types for all resources
X-Frame-Options	High	Low	5	Mandatory for all websites	Websites that don't use DENY or SAMEORIGIN must employ clickjacking defenses
X-XSS-Protection	Low	Medium	13	Mandatory for all new websites Recommended for existing websites	Manual testing should be done for existing websites, prior to implementation

^† 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 noted in your risk assessment.

Compatibility

Configuration	Oldest compatible clients
Modern	Firefox 27, Chrome 22, Internet Explorer 11, Opera 14, Safari 7, Android 4.4, Java 8
Intermediate	Firefox 1, Chrome 1, Internet Explorer 7, Opera 5, Safari 1, Internet Explorer 8 (XP), Android 2.3, Java 7
Backwards Compatible (Old)	Internet Explorer 6 (XP), Java 6

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.mozilla.com will also set it on host1.domain.mozilla.com and host2.domain.mozilla.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

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 occured, 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.

Redirections should be done with the 301 redirects, unless they redirect to a different path, in which case they may be done with 302 redirections. Sites should avoid redirections from HTTP to HTTPS on a different host, as this prevents HSTS from being set.

Examples

# Redirect all incoming http requests to the same site and URI on https, using nginx
server {
  listen 80;

  return 301 https://$host$request_uri;
}

# Redirect for site.mozilla.org from http to https, using Apache

  ServerName site.mozilla.org
  Redirect permanent / https://site.mozilla.org/

HTTP Public Key Pinning

Maximum risk sites must enable the use of HTTP Public Key Pinning (HPKP). HPKP instructs a user agent to bind a site to specific root certificate authority, intermediate certificate authority, or end-entity public key. This prevents certificate authorities from issuing unauthorized certificates for a given domain that would nevertheless be trusted by the browsers. These fradulent certificates would allow an active attacker to MitM and impersonate a website, intercepting credentials and other sensitive data.

Due to the risk of knocking yourself off the internet, HPKP must be implemented with extreme care. This includes having backup key pins, testing on a non-production domain, testing with Public-Key-Pins-Report-Only and then finally doing initial testing with a very short-lived max-age directive. Because of the risk of creating a self-denial-of-service and the very low risk of a fraudulent certificate being issued, it is not recommended for the majority websites to implement HPKP.

Directives

max-age: how long the user agent the keys will be pinned; the site must use a cert that meets these pins until this time expires
includeSubDomains: whether user agents should pin all subdomains to the same pins

Unlike with HSTS, what to set max-age is highly individualized to a given site. A longer value is more secure, but screwing up your key pins will result in your site being unavailable for a longer period of time. Recommended values fall between 15 and 120 days.

Examples

# Pin to DigiCert, Let's Encrypt, and the local public-key, including subdomains, for 15 days
Public-Key-Pins: max-age=1296000; includeSubDomains; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";
  pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="P0NdsLTMT6LSwXLuSEHNlvg4WxtWb5rIJhfZMyeXUE0="

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 occuring, developers should verify that all resources are loaded securely prior to deployment.

Examples

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

# Generate the hash myself $ curl -s https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js | \ openssl dgst -sha384 -binary | \ openssl base64 -A r1y8TJcloKTvouxnYsi4PJAx+nHNr90ibsEn3zznzDzWBN9X3o3kbHLSgcIPtzAp See Also SRI Hash Generator - generates

Security/Guidelines/Web Security

Contents

Web Security Cheat Sheet

Transport Layer Security (TLS/SSL)

HTTPS

Compatibility

See Also

HTTP Strict Transport Security

Directives

Examples

See Also

HTTP Redirections

Examples

HTTP Public Key Pinning

Directives

Examples

See Also

Resource Loading

Examples

See Also

Content Security Policy

See Also