Difference between revisions of "OWASP Secure Headers Project"

A list of headers related to security and how to implement them properly.

• HTTP Strict Transport Security (HSTS)
• Public Key Pinning Extension for HTTP (HPKP)
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options
• Content-Security-Policy

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. HSTS is an IETF standards track protocol and is specified in RFC 6797. A server implements an HSTS policy by supplying a header (Strict-Transport-Security) over an HTTPS connection (HSTS headers over HTTP are ignored).

Values

Value	Description
max-age=SECONDS	The time, in seconds, that the browser should remember that this site is only to be accessed using HTTPS.
includeSubDomains	If this optional parameter is specified, this rule applies to all of the site's subdomains as well.

Example

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

Best Practices

• Apache

Edit your apache configuration file and add the following to your VirtualHost.

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"

• nginx

Edit your nginx configuration file and add the following snippet.

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";

• lighttpd

Edit your lighttpd configuration file and add the following snippet.

setenv.add-response-header = ("Strict-Transport-Security" => "max-age=63072000; includeSubdomains",)

• IIS

References

• https://tools.ietf.org/html/rfc6797
• https://www.owasp.org/index.php/List_of_useful_HTTP_headers
• https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
• https://www.chromium.org/hsts
• https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
• https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html

Public Key Pinning Extension for HTTP (HPKP)

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. (For example, sometimes attackers can compromise certificate authorities, and then can mis-issue certificates for a web origin.) The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use 1 or more of those public keys in its certificate chain.

Values

Value	Description
pin-sha256="<sha256>"	The quoted string is the Base64 encoded Subject Public Key Information (SPKI) fingerprint. It is possible to specify multiple pins for different public keys. Some browsers might allow other hashing algorithms than SHA-256 in the future.
max-age=SECONDS	The time, in seconds, that the browser should remember that this site is only to be accessed using one of the pinned keys.
includeSubDomains	If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
report-uri="<URL>"	If this optional parameter is specified, pin validation failures are reported to the given URL.

Example

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

Best Practices

• Apache

Edit your apache configuration file and add the following to your VirtualHost.

Header set Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains"

• nginx

Edit your nginx configuration file and add the following snippet.

add_header Public-Key-Pins "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains";

• lighttpd

Edit your lighttpd configuration file and add the following snippet.

setenv.add-response-header = ("Public-Key-Pins" => "pin-sha256=\"klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=\"; pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; max-age=2592000; includeSubDomains",)

• IIS

References

• https://tools.ietf.org/html/rfc7469
• https://www.owasp.org/index.php/List_of_useful_HTTP_headers
• https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
• https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
• https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

X-Frame-Options

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

Values

Value	Description
deny	No rendering within a frame.
sameorigin	No rendering if origin mismatch.
allow-from: DOMAIN	Allows rendering if framed by frame loaded from DOMAIN.

Example

X-Frame-Options: deny

Best Practices

• Apache

Add this line below into your site's configuration to configure Apache to send X-Frame-Options header for all pages.

Header set X-Frame-Options DENY

• nginx

Add snippet below into configuration file to send X-Frame-Options header.

add_header X-Frame-Options "DENY";

• lighttpd

Add snippet below into configuration file to send X-Frame-Options header.

setenv.add-response-header = ("X-Frame-Options" => "DENY",)

• IIS

References

• https://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01
• https://tools.ietf.org/html/draft-ietf-websec-frame-options-00
• https://www.owasp.org/index.php/List_of_useful_HTTP_headers

X-XSS-Protection

This header enables the Cross-site scripting (XSS) filter.

Values

Value	Description
0	Filter disabled.
1	Filter enabled. If a cross-site scripting attack is detected, in order to stop the attack, the browser will sanitize the page.
1; mode=block	Filter enabled. Rather than sanitize the page, when a XSS attack is detected, the browser will prevent rendering of the page.
1; report=http://[YOURDOMAIN]/your_report_URI	Filter enabled. The browser will sanitize the page and report the violation. This is a Chromium function utilizing CSP violation reports to send details to a URI of your choice.

Example

X-XSS-Protection: 1; mode=block

Best Practices

Add appropriate snippet into configuration file.

• Apache

Header set X-XSS-Protection: 1; mode=block

• nginx

add_header X-XSS-Protection "1;mode=block";

• lighttpd

setenv.add-response-header = ("X-XSS-Protection" => "1; mode=block",)

• IIS

References

• https://www.owasp.org/index.php/List_of_useful_HTTP_headers
• https://www.virtuesecurity.com/blog/understanding-xss-auditor/
• https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers
• http://zinoui.com/blog/security-http-headers#x-xss-protection

X-Content-Type-Options

Setting this header will prevent MSIE and Chrome from interpreting files as something else than declared by the content type in the HTTP headers.

Values

Value	Description
nosniff	will prevent Internet Explorer and Chrome from MIME-sniffing a response away from the declared content-type.

Example

X-Content-Type-Options: nosniff

Best Practices

Add appropriate snippet into configuration file.

• Apache

Header set X-Content-Type-Options: nosniff

• nginx

add_header X-Content-Type-Options "nosniff";

• lighttpd

setenv.add-response-header = ("X-Content-Type-Options" => "nosniff",)

• IIS

References

• https://www.owasp.org/index.php/List_of_useful_HTTP_headers
• https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/

Content-Security-Policy

Content Security Policy requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browser renders pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

Values

Directive	Description
base-uri	Define the base uri for relative uri.
default-src	Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback).
script-src	Define which scripts the protected resource can execute.
object-src	Define from where the protected resource can load plugins.
style-src	Define which styles (CSS) the user applies to the protected resource.
img-src	Define from where the protected resource can load images.
media-src	Define from where the protected resource can load video and audio.
frame-src	Deprecated and replaced by child-src. Define from where the protected resource can embed frames.
child-src	Define from where the protected resource can embed frames.
frame-ancestors	Define from where the protected resource can be embedded in frames.
font-src	Define from where the protected resource can load fonts.
connect-src	Define which URIs the protected resource can load using script interfaces.
manifest-src	Define from where the protected resource can load manifest.
form-action	Define which URIs can be used as the action of HTML form elements.
sandbox	Specifies an HTML sandbox policy that the user agent applies to the protected resource.
script-nonce	Define script execution by requiring the presence of the specified nonce on script elements.
plugin-types	Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded.
reflected-xss	Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header.
block-all-mixed-content	Prevent user agent from loading mixed content.
upgrade-insecure-requests	Instructs user agent to download insecure resources using HTTPS.
referrer	Define information user agent must send in Referer header.
report-uri	Specifies a URI to which the user agent sends reports about policy violation.
report-to	Specifies a group (defined in Report-To header) to which the user agent sends reports about policy violation.

Example

Content-Security-Policy: script-src 'self'

Best Practices

Add appropriate snippet into configuration file.

• Apache

Header set Content-Security-Policy: script-src 'self'

• nginx

add_header Content-Security-Policy "script-src 'self'";

• lighttpd

setenv.add-response-header = ("Content-Security-Policy" => "script-src 'self'",)

• IIS

References

• https://www.owasp.org/index.php/List_of_useful_HTTP_headers
• http://www.cspplayground.com/home
• https://scotthelme.co.uk/content-security-policy-an-introduction/

A list of tools that can help you to achieve the on of the goals of this project.

High-Tech Bridge Web Security Scanner

An online service that will retrieve and analyse headers syntax and proper configuration in a comprehensive way. It will be able for instance to highlight Public-Key-Pins that matches one certificate of the chain or if Content-Security-Policy contains values that could be unsafe or too permissive.

Site: https://www.htbridge.com/websec/

hsecscan

A security scanner for HTTP response headers.

Github: https://github.com/riramar/hsecscan

securityheaders.io

There are services out there that will analyse the HTTP response headers of other sites but I also wanted to add a rating system to the results. The HTTP response headers that this site analyses provide huge levels of protection and it's important that sites deploy them. Hopefully, by providing an easy mechanism to assess them, and further information on how to deploy missing headers, we can drive up the usage of security based headers across the web.

Site: https://securityheaders.io

report-uri.io

When a site deploys a Content Security Policy or HTTP Public Key Pinning, the browser will enforce the security policies declared by the site. This is great as it offers visitors more protection but the only problem is, the host doesn't know that there's a problem. The browser will block malicious content, such as an XSS attack, but the host wouldn't know anything about it and as such, can't resolve the problem. This is the problem that report-uri.io fixes. With your own unique reporting endpoint the browser can send a violation report to us and you can monitor exactly what is happening on your site. You can see what security policies are being triggered, where and why.

Site: https://report-uri.io

secureheaders

secure_headers is a library for ruby with a global config, per request overrides, and rack milddleware that enables you customize your application settings.

Github: https://github.com/twitter/secureheaders

Security Header Injection Module (SHIM)

SHIM is a HTTP module that provides protection for many vulnerabilities by injecting security-specific HTTP headers into ASP.NET web applications.

Site: https://shim.codeplex.com

http_hardening

Puppet module to enable, configure and manage secure http headers in web servers.

Github: http_hardening
Forge: http_hardening at forge | puppetlabs

What is HTTP header?

HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction.

Is there a standard for HTTP headers?

A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFCs 7230, 7231, 7232, 7233, 7234, and 7235. The permanent registry of header fields and repository of provisional registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application. Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard. An earlier restriction on use of Downgraded- was lifted in March 2013.

Contributors

OWASP Secure Headers Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

• Ricardo Iramar
• Jim Manico
• Alexandre Menezes

2016 Priorities

To Do

OWASP Secure Headers Project intends to raise awareness and usage of headers sent by the server that can increase security. We'll aim to bring this about by:

• Producing open source, easily implemented, well documented code libraries that enable these headers for a variety of platforms. We'll prioritize creating and publicizing Node.JS, PHP, Ruby, and Java, but will eventually reach out towards edge cases like Go, Python and others. The key is to make this accessible as possible to developers.

• Improve constantly hsecscan tool to detect bad practices and provide link to the best practices above.

• Perform public to scan websites using hsecscan and view stats regarding these headers. Automated scanning of the top 1m sites on the web; filtering of said sites to view stats across industries and countries; published database dumps for public consumption/tools; scanning of individual sites; comparing multiple scanned sites.

• Consistent reports regarding this secure headers, their usage, any changes to existing headers.

Involvement in the development and promotion of OWASP Secure Headers Project is actively encouraged! You do not have to be a security expert in order to contribute. If you want to help send an email to [email protected].

Doing

• Including how to set properly secure headers on IIS.

Done

• Creating secure best practices implementations including how to set properly secure headers on the most common platforms (eg. Apache, NGINX and Lighttpd).