Add the following headers

[codelion]

Refer to the disc here

Can we see how we can add the following HTTP headers to the tool as well. @CalebFenton will provide with the scoring guide for them.

• Access-Control-Allow-Origin
• X-Powered-By
• Content-Type: text/html; charset=utf-8
• Server

[CalebFenton]

We can add warnings for X-Powered-By and Server for sure.

We can also warn in the cases where Content-Type is text/html and charset is not utf-8.

Secure use of Access-Control-Allow-Origin header seems highly context dependent. Below are some suggestions from the specification http://www.w3.org/TR/cors/:

Most of the time a "*" value is fine, or the header shouldn't be set at all:

• A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value is "*".
• A resource that is not useful to applications from other origins, such as a login page, ought not to return an Access-Control-Allow-Origin header.

An obvious resource with access controls is one with credentials. In these cases, a header should be used: If the resource supports credentials add a single Access-Control-Allow-Origin header, with the value of the Origin header as value

But a wildcard value is invalid: The string "*" cannot be used for a resource that supports credentials.

This leaves only resources with access control checks that don't support credentials. I don't think it's a good idea to even warn because it seems that, in most cases, without knowing anything else about the resource, a "*" value for Access-Control-Allow-Origin is probably fine.

[codelion]

@CalebFenton Agreed, lets add only X-Powered-By, Server and Content-Type. How do you think the scoring should work for these?

So if X-Powered-By and Server are set we can show a warning (zero score) with text Setting this header may reveal unnecessary information about server configuration.

But what should we do when these headers are not set. Should we give it a +1 or still score zero but show green color with text Not setting this header prevents unnecessary information about server configuration from being disclosed.?

For Content-Type the question is similar how do we grade it? We can warn with zero score when test/html is set but charset is not utf-8 (with text Please ensure that the character set matches with the content type.). But what should we do in other cases: when the header is not set we can may be give a warning with zero score and text Please specify the content type and character set in the response header. In all other cases we can may be say something like Setting content type and character set prevents against content sniffing and character set mismatch. and give them zero score but with green color?

[CalebFenton]

I updated our scoring spreadsheet with warning text similar to what you suggested above.

In the case of content type not being set, I think it's a good idea to warn. RFC2616 says:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.

And SHOULD is described in RFC2119:

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

If X-Powered-By or Server is present, warn with:

Removing this header prevents unnecessary information about server configuration from being disclosed.

If Content-Type is present and set to text/html and charset is not utf-8 (case insensitive):

The HTML5 specification encourages developers to include charset=utf-8 for text/html content types.

If Content-Type is not set:

Setting content type and character set prevents against content sniffing and character set mismatch.

[codelion]

Closing this as new headers have already been added!