Secure your WordPress sites with Advanced HTTP Security Headers

Shield's HTTP Headers module is composed of the 2 parts (features). The Advanced Security Headers is one of its features.

Security is as important as content of your website, and many of website get hacked due to misconfiguration or lack of protection. If you are a website owner or security engineer and looking to protect your website from Clickjacking, code injection, MIME types, XSS, etc. attacks then this feature will help you.

What is the Advanced Security Headers feature and how does it work?

The Advanced Security Headers feature is designed to protect visitors to your site by implementing increased HTTP Security Response Headers. It gives you the ability to set certain HTTP Security Headers. The particular Headers available are:

Block iFrames
XSS Protection
Prevent Mime-Sniff
Referrer Policy

Security Header: Block iFrames

An iFrame (Inline Frame) is an HTML document embedded inside another HTML document on a website. The IFrame HTML element is often used to insert content from another source, such as an advertisement, into a web page.

The hackers can insert IFrame code into the saved search results of legitimate websites. When a visitor clicks on a link from the compromised search tool, he would be redirected to a malicious website by the IFrame code. The unsuspecting user's computer would then be vulnerable to the automatic download of malware.

The iFrames Security Header improves the protection of web applications against ClickJacking. It lets you direct a web browser as to whether your site content may be displayed/embedded within frame on another web page e.g. through the use of iFrames ( <iframe> ).

To set this Security Header, select one of the options available from the drop down list (see the screenshot below). The options available are as follows:

Off: iFrames not blocked - Always allow browsers to load page in an iFrame.
On: Allow iFrames on the same domain, directive "SAMEORIGIN" - A page may only be framed by other pages on the same origin. In other words, pages on the same domain can include each other in an iFrame.
On: Block all iFrames, directive "DENY" - Never allow browsers to load page in an iFrame.

Security Header: XSS Protection

Certain browsers come with XSS (Cross-site scripting) protection built into them. These may, for whatever, be on or off and you now have the control to explicitly turn on this extended browser protection.

XSS is a security vulnerability where a hacker manages to run code, which the browser treats as being from the website. This means the web browser gives it access to all the same information and resources that the website has (e.g. access to cookies).

Shield's XSS Protection Security Header directs compatible browsers to block what they detect as Reflective XSS attacks.

Security Header: Prevent Mime-Sniff

This Security Header reduces visitor exposure to malicious user-uploaded content.

It prevents certain browsers from loading content where there is a MIME type mismatch. An example of where this is useful is where certain, say user-uploaded Javascript files are actually not true Javascript files and it prevents loading of files where the mime types don’t match correctly.

Security Header: Referrer Policy

The HTTP Referrer is an HTTP Header field that identifies the address of the webpage that linked to the resource being requested. By checking the referrer, the new webpage can see where the request originated.

In the most common situation this means that when a user clicks a hyperlink in a web browser, the browser sends a request to the server holding the destination webpage. The request includes the referrer field, which indicates the last page the user was on (the one where they clicked the link).

Referrer logging is used to allow websites and web servers to identify where people are visiting them from, for promotional or statistical.

Shield's Referrer Policy Header allows you to control when and what referral information a browser may pass along with links clicked on your site.

Note: Before you set Referrer Policy Header, we recommend you to read the further sommary on this here.

To set this Security Header, select one of the options available from the drop down list (see the screenshot below).

The options available are as follows:

Default: Full Referrer URL (AKA "Unsafe URL"), directive "unsafe-url" - The browser will always send the full URL with any request to any origin.
No Referrer, directive "no-referrer" - Instructs the browser to never send the Referrer Header with requests that are made from your site. This also include links to pages on your own site.
No Referrer When Downgrade, directive "no-referrer-when-downgrade" - The browser will not send the Referrer Header when navigating from HTTPS to HTTP, but will always send the full URL in the Referrer Header when navigating from HTTP to any origin.
Same Origin, directive "same-origin" - The browser sends the full URL if it’s the same domain, but strips the value if going to another website.
Strict Origin, directive:"strict-origin" - The browser will always set the Referrer Header to the origin from which the request was made. It sends the domain for HTTPS > HTTPS and HTTP > HTTP, but not HTTPS > HTTP.
Origin When Cross-Origin, directive "origin-when-cross-origin" - The browser sends the full URL when on the same domain, but only the domain when passing to another website.
Strict Origin When Cross-Origin, directive "strict-origin-when-cross-origin" - The browser sends the full URL if on the same domain and from one secure page to another. It doesn’t pass if going from a secure domain to an insecure domain.
Empty Header, directive: "Referrer-Policy"; - Indicates that the site doesn't want to set a Referrer Policy here and the browser should fallback to a Referrer Policy defined via other mechanisms elsewhere.
Don't Send This Header - The browser will not send this Referrer Header.

To dig into these Advanced HTTP Security Headers a little more, you can read a further summary on this over at ScottHelme here.