The main tool we recommend is https://securityheaders.io
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
Though this is not only about HTTP headers browserscope.org gives interesting view on what is supported by top browsers
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
Referrer-Policy
We use the same that Firefox default: no-referrer-when-downgrade
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)
Content Security Policy
I'd like to use the safer one OOTB, ie in Java: resp.setHeader("Content-Security-Policy", "default-src 'self'");
This means that all resources links should be local. The resources types are: script, object (plugins), style, img, media, frame, font, connect and form.
No need to say that it's very ambitious and not for today.
The 1st task to handle is to remove as much as possible JavaScript snippets and have as much as possible JavaScript files.
There are already few Jiras about that and we are slowly heading in the right direction.
It's not sure we can reach this very ambitious goal and the good news is that it's not a problem if we don't.
When we will hit cases where local it's not possible then we can define so called nonce to be sure the resources are loaded from the right place.
In no case we should OOTB use the lazy unsafe-inline and eval-inline
To not block anything for the moment I have committed a simple most restrictive Content-Security-Policy-Report-Only header at r1812720
Then we can look at the issues using browsers tools (there are so much)
The next step is to report the errors (when there will not be too much) in the log using a report-uri
And ultimately to use OOTB the most simple and constraining policy, with exceptions of course (as ever).
Note: if we encounter performance issue we can comment out the current Content-Security-Policy-Report-Only
Some links
https://scotthelme.co.uk/content-security-policy-an-introduction/
https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy
https://csp.withgoogle.com/docs/adopting-csp.html
https://content-security-policy.com/
Related Jira issues:
OFBIZ-6759 - Getting issue details... STATUS
OFBIZ-6766 - Getting issue details... STATUS
OFBIZ-6655 - Getting issue details... STATUS