HTTP Header Series: The "Xs"

In our opening to this series, we discussed some of the reasons for Security Headers.  In this post we will describe in more detail some of the security headers that still bear the “X” prefix.  Custom proprietary headers have historically been used with an "X-" prefix, but this convention was deprecated in June 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648.  Regardless, in this post we will discuss four “X” headers that made it to primetime and are important when discussing security.

X-Frame-Options

The X-Frame-Options response header improves the protection of web applications against clickjacking. This header informs the browser as to whether the content of third-party websites can be displayed within frames.   This is includes all <frame>, <iframe>, <embed> and <object> tags.

X-Frame-Options Syntax:

X-Frame-Options: Directive

 

X-Frame-Options Directives:

Directive	Description
DENY	The page cannot be displayed in a frame, regardless of the site attempting to do so.
SAMEORIGIN	The page can only be displayed in a frame on the same origin as the page itself. The spec leaves it up to browser vendors to decide whether this option applies to the top level, the parent, or the whole chain, although it is argued that the option is not very useful unless all ancestors are also in the same origin.

 

Examples:

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

 

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is simply used to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed verbatim. This is a way to opt out of MIME type sniffing, or, in other words, to say that the MIME types are deliberately configured.

X-Content-Type-Options Syntax:

X-Frame-Options: nosniff

The “nosniff” directive is the only directive available in this header and indicate the MIME types are deliberately configured and should not be “sniffed” or inferred.

NOTE: If you are a Sitecore user, this header may interfere with your use of the Experience Editor and should be disabled.

X-Permitted-Cross-Domain-Policies

This header is used to allow Flash and PDF documents to request data from other domains.  In general, the permission set is described in an XML document named crossdomain.xml and found in the root path of the web site. The format specification for this policy file can be found here. When clients request content hosted on a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain needs to host a crossdomain.xml file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

In general, if you are hosting static PDF files, this header is not required.

X-Permitted-Cross-Domain-Policies Syntax:

X-Permitted-Cross-Domain-Policies: Directive

 

X-Permitted-Cross-Domain-Policies Directives:

Directive	Description
none	No policy files are allowed anywhere on the target server, including this master policy file.
master-only	Only this master policy file is allowed.
by-content-type	Only policy files served with Content-Type: text/x-cross-domain-policy are allowed. (HTTP/HTTPS only)
by-ftp-filename	Only policy files whose file names are crossdomain.xml (i.e. URLs ending in /crossdomain.xml) are allowed. (FTP only)
all	All policy files on this target domain are allowed.

 

Examples:

X-Permitted-Cross-Domain-Policies: none

X-Permitted-Cross-Domain-Policies: all

 

X-XSS-Protection

This header has been deprecated and we suggest using the Content-Security-Policy header instead.