Confirmed users
502
edits
Security/Guidelines/Web Security: Difference between revisions
Security/Guidelines/Web Security (view source)
Revision as of 22:38, 19 October 2017
, 19 October 2017Automated sync from https://github.com/mozilla/wikimo_content
(Automated sync from https://github.com/mozilla/wikimo_opsec) |
Gdestuynder (talk | contribs) (Automated sync from https://github.com/mozilla/wikimo_content) |
||
| Line 235: | Line 235: | ||
* <tt>max-age:</tt> how long user agents will redirect to HTTPS, in seconds | * <tt>max-age:</tt> how long user agents will redirect to HTTPS, in seconds | ||
* <tt>includeSubDomains:</tt> whether user agents should upgrade requests on subdomains | * <tt>includeSubDomains:</tt> whether user agents should upgrade requests on subdomains | ||
* <tt>preload:</tt> whether the site should be included in the [https://hstspreload. | * <tt>preload:</tt> whether the site should be included in the [https://hstspreload.org/ HSTS preload list] | ||
<tt>max-age</tt> 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. | <tt>max-age</tt> 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. | ||
| Line 241: | Line 241: | ||
<tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS. For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled. | <tt>includeSubDomains</tt> notifies the browser that all subdomains of the current origin should also be upgraded via HSTS. For example, setting <tt>includeSubDomains</tt> on <tt>domain.mozilla.com</tt> will also set it on <tt>host1.domain.mozilla.com</tt> and <tt>host2.domain.mozilla.com</tt>. Extreme care is needed when setting the <tt>includeSubDomains</tt> flag, as it could disable sites on subdomains that don't yet have HTTPS enabled. | ||
<tt>preload</tt> allows the website to be included in the [https://hstspreload. | <tt>preload</tt> allows the website to be included in the [https://hstspreload.org/ 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 <tt>includeSubDomains</tt> also be set. | ||
=== Examples === | === Examples === | ||
| Line 445: | Line 445: | ||
== Directives == | == Directives == | ||
* Name: Cookie names may be either be prepended with either <tt>__Secure-</tt> or <tt>__Host-</tt> to prevent cookies from being overwritten by insecure sources | |||
** Use <tt>__Host-</tt> for all cookies needed only on a specific domain (no subdomains) where <tt>Path</tt> is set to <tt>/</tt> | |||
** Use <tt>__Secure-</tt> for all other cookies sent from secure origins (such as HTTPS) | |||
* <tt>Secure</tt>: All cookies must be set with the <tt>Secure</tt> flag, indicating that they should only be sent over HTTPS | * <tt>Secure</tt>: All cookies must be set with the <tt>Secure</tt> flag, indicating that they should only be sent over HTTPS | ||
* <tt>HttpOnly:</tt> Cookies that don't require access from JavaScript should be set with the <tt>HttpOnly</tt> flag | * <tt>HttpOnly:</tt> Cookies that don't require access from JavaScript should be set with the <tt>HttpOnly</tt> flag | ||
| Line 452: | Line 455: | ||
* <tt>Domain:</tt> Cookies should only be set with this if they need to be accessible on other domains, and should be set to the most restrictive domain possible | * <tt>Domain:</tt> Cookies should only be set with this if they need to be accessible on other domains, and should be set to the most restrictive domain possible | ||
* <tt>Path:</tt> Cookies should be set to the most restrictive path possible, but for most applications this will be set to the root directory | * <tt>Path:</tt> Cookies should be set to the most restrictive path possible, but for most applications this will be set to the root directory | ||
== Examples == | == Examples == | ||
| Line 473: | Line 470: | ||
* [https://tools.ietf.org/html/rfc6265 RFC 6265 (HTTP Cookies)] | * [https://tools.ietf.org/html/rfc6265 RFC 6265 (HTTP Cookies)] | ||
* [https://tools.ietf.org/html/draft-west-cookie-prefixes HTTP Cookie Prefixes | * [https://tools.ietf.org/html/draft-west-cookie-prefixes HTTP Cookie Prefixes] | ||
| Line 726: | Line 723: | ||
! scope="col" style="width: 6em;" | Editor | ! scope="col" style="width: 6em;" | Editor | ||
! Changes | ! Changes | ||
|- | |||
| style="padding-left: .5em; text-align: left;" | June, 2017 | |||
| align="center" | April | |||
| style="padding-left: .5em;" | Moved cookie prefixes to no longer be experimental | |||
|- | |- | ||
| style="padding-left: .5em; text-align: left;" | November, 2016 | | style="padding-left: .5em; text-align: left;" | November, 2016 | ||