Establish a CSP and Security Headers standard

X-Frame-Options

We previously reviewed the benefits of using the X-Frame-Options as a response HTTP header to help address clickjacking security vulnerabilities in web applications.

That being said, practices evolve and browsers rapidly adopt new standards and mechanisms. For example, the ALLOW-FROM value for the X Frame Options header has been deprecated and is now discouraged because modern browser versions don’t support it anymore.

As a migration path, the Content Security Policy standards create a way to adapt to such new standards. One such way is CSP’s frame-ancestors directive. For example, setting its value to 'none' should be compatible with X-Frame-Options setting of DENY value.

A more complete example of the Content Security Policy in action for clickjacking security controls is:

Content-Security-Policy: frame-ancestors 'none';

The above CSP will disallow any URLs of embeddable content in iframe, object, and other HTML elements which are part of the frame-ancestors policy.

Do note, however, that older browsers may not respect Content-Security-Policy and its directives. As such, you may actually cause a degraded security status.

To avoid such a problem, consult your supported browser matrix requirements and employ both old and new headers to ensure all bases are covered.

X-XSS-Protection

Similar to the case with the X Frame Options HTTP header, the X-XSS-Protection header is considered deprecated and should mandate that you establish and roll out a Content Security Policy HTTP header instead.

It’s still useful to keep as a header if you are targeting older browsers, but otherwise note that Chrome and Edge removed their XSS auditor and Firefox isn’t planning on implementing support for X-XSS-Protection.

Following is the browser compatibility matrix for the header as listed on MDN: