THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
The main tools we recommend are https://securityheaders.io/ and https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Though this is not only about HTTP headers browserscope.org gives interesting view on what is supported by top browsers
Here is the state we had (2015-12-12):
And here is the current state https://s.apache.org/Pggc
Here are some documentation and links for each header:
Global references
https://blog.appcanary.com/2017/http-security-headers.html
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
X-Frame-Options
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#X-Frame-Options_Header_Types
https://www.owasp.org/index.php/Clickjacking
https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options (interesting for devops, tells about Apache, Nginx and HAProxy)
Strict-Transport-Security
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html (for devops)
About the preload issue if you really care: https://hstspreload.appspot.com/
X-Content-Type-Options
According to Wikipedia and Owasp, the only defined value, "nosniff", prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions. Not Firefox yet.
X-XSS-Protection
This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
It's usually enabled by default anyway, so the role of this header is to re-enable the filter for this particular website if it was disabled by the user.
This header is supported in IE 8+, and in Chrome (not sure which versions). The anti-XSS filter was added in Chrome 4. Its unknown if that version honored this header.
FireFox has still an open bug entry and "offers" only the noscript plugin.
https://wiki.mozilla.org/Security/Features/XSS_Filter
https://bugzilla.mozilla.org/show_bug.cgi?id=528661
While working on a mean to introduce this in OFBiz I stumbled upon this exchange between Jacopo and Mark Thomas about HttpHeaderSecurityFilter on the Tomcat users ML. See my conclusion here.
Set-Cookie
The secure flag on cookies instructs the browser to only submit the cookie as part of requests over secure (HTTPS) connections. This prevents the cookie from being observed as plain text in transit over the network.
The HttpOnly flag instructs the browser that this cookie can only be accessed when sending an HTTP request. This prevents scripts running as part of a page from retrieving the value and is a defense against XSS attacks.
https://www.owasp.org/index.php/HttpOnly
https://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OWASP-SM-002%29
https://tomcat.apache.org/migration-7.html#Session_cookie_configuration This is not Tomcat 7 specific but Servlet 3.0 standard!
X-Powered-By
It's recommended to not use the X-Powered-By header. Including information about the server provides no tangible benefit to either the browser or user. It can direct an attacker to known vulnerabilities in the server version and should therefore be avoided.
Tomcat documentation: <<The xpoweredBy attribute controls whether or not the X-Powered-By HTTP header is sent with each request. If sent, the value of the header contains the Servlet and JSP specification versions, the full Tomcat version (e.g. Apache Tomcat/7.0.0), the name of the JVM vendor and the version of the JVM. This header is disabled by default. This header can provide useful information to both legitimate clients and attackers.>>
OFBiz users can decide to change this parameter if they want
Public-Key-Pins-Report-Only
To use in custom project only. Public-Key-Pins-Report-Only is interesting but can't be used OOTB because of demos (the letsencrypt certificate is renewed every 3 months)
Related Jira issues: