Questo contenuto è disponibile in Italiano
Why are HTTP Security Headers important and what are they?
We might think of HTTP Security Headers as something extremely technical.
In reality, this aspect of the structure of a blog or website needs to be investigated and addressed in the best possible way if you want to work in an SEO optimization perspective and maintain a high functionality of your portal.
Put another way, you cannot be online and ignore this topic: it is a parameter related to the security of the website, a security that today is part of the parameters known as Google Page Experience, which is an overall evaluation of the various elements that make up the user experience.
Inside we also find Core Web Vitals, optimization for mobile, the presence of HTTPS and, indeed, web page security.
HTTP Security Headers are directives, related to the security of the website, that are transmitted through theHTTP header response, which is the response that the web server gives to the browser software that is trying to access the website.
The client, the program you use to browse, connects to your web space through a domain and receives various information.
Such as the status code (200 if okay, 404 if bad).
HTTP Security Headers related security headers define limits and instructions that prevent unwanted and dangerous actions to your work published on the Internet.
These elements are responsible for defining an advanced level of security.
By limiting the behaviors allowed by the browser and the server (thus data request and response) once an action is performed by the user or a bot. Automated software is always scanning websites for security weaknesses.
Sure, you can work on other fronts as well, such as using plugins to increase security and mounting a good firewall or using quality hosting.
But that’s not always enough, which is why HTTP Security Headers come into play.
Let’s look together at the main guidelines you can use:
Strict Transport Security (HSTS) – restrictive security on the HTTP transport
The Strict-Transport-Security header (often shortened to HSTS) informs browsers that the site must be accessed only via HTTPS protocol and that any future attempts to access it via HTTP must be automatically converted to HTTPS.
This is more secure than a common 301 redirect, which would allowman-in-the-middle attacks.
Through parameters, it is possible to set the maximum time for browsers to store the setting, as well as the application to subdomains.
Example: Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Content Security Policy (CSP) – Content Security Policy
This solution is designed to anticipate and defuse a wide range of attacks, including cross-site scripting that uses a vulnerability in website security.
Through such levity, such as using unsafe plugins or not updating WordPress themes, attackers can launch malicious scripts on a website that are then downloaded to the user’s browser (in which case, the portal could be banned by Google with irreparable damage).
The Content Security Policy requires the browser to download only resources from a certain group of domains, consequently if the content security policy you apply is very restrictive you have to consider that it can have negative effects on the logic of your website, because there are many resources to be blocked!
This security header is recommended for websites that handle sensitive user data, if you have a simple blog or informational site its usefulness is greatly reduced.
Also you have to consider that it is not super easy to enable all CSP security features since you may need numerous customizations to the WordPress or website code.
For example, to enable nonce-based strict CSP you will have to edit callbacks to all dependencies used by the website, and that is not always trivial.
On the other hand, if you want to choose to enable hash-based strict CSP you will have to include all inline scripts in your HTML template, because browsers are not allowed to use hashes on external dependencies.
Two opposing methods that require major interventions to HTML templates and dependency inclusions.
An example directive: Content-Security-Policy: font-src font.example.com;
X-Content-Type-Options
This header is used by the server to signal that the MIME types specified for the various content published on the page (images, files, Javascript, etc.) must be respected and not changed.
This avoids misinterpretation of files: this would become crucial if a malicious file is masked as a different file type, exploiting the MIME type sniffing technique: this vulnerability occurs when a site allows data to be uploaded to the server and a user masks an HTML file as a different file type and this allows a security breach to open.
It is triggered by the directive: X-Content-Type-Options: nosniff
Referrer Policy – Policy on Referrer
This directive determines what information is passed to the landing site of a link placed on your Web site whenever you leave a page.
Various options are available based on protocol (HTTP or HTTPS) and site (whether the same or another).
The purpose of a Referrer-Policy header is to control what information is sent when a visitor leaves your pages to visit another portal.
The default is to send domain, path and query string if you stay on the same site.
For outbound queries you send the domain in case you stay on HTTPS.
No data is sent should you switch to HTTP.
With the no-referrer command the header will be omitted altogether, example: Referrer-Policy: no-referrer
Clear Site Data (CSD)
The Clear-Site-Data parameter clears browsing data (cookie type, cache) related to the website.
It allows webmasters to have more control over the information stored by a browsing browser.
This header is useful during a logout process, for example, it ensures that all content stored on the browser is removed.
In the header syntax you can indicate individual parameters to be deleted or use the asterisk to include all of them, including future ones that will be added.
Example: Clear-Site-Data: “cache”, “cookies”, “storage”
Permissions Policy
Permissions Policy provides mechanisms that allow developers to explicitly declare what functionality can and cannot be used on a site.
It defines a set of “policies” that restrict which APIs your site’s code can access or change the browser’s default behavior for certain functionality.This allows you to apply best practices and more securely compose third-party content.
Permissions Policy is similar to CSP but controls functionality instead of security behavior.
Examples of what you can do with Permissions Policy:
- Changes the default behavior of automatic playback on mobile and third-party videos;
- limits a site’s use of sensitive devices such as a camera, microphone, or speakers;
- allow iframes to use the ‘full-screen API;
- stops executing scripts on elements if they are not visible in the viewport, to improve performance.
X-Frame-Options
The X-Frame-Options header is a security measure that prevents the browser from loading web pages in a <frame>, <iframe>, <embed> o <object>.
L’abilitazione delle intestazioni di risposta HTTP X-Frame-Options consente di difendersi dagli attacchi Cross-Frame Scripting (XFS), dal clickjacking e da altre forme di attacco informatico: attivandola, i tuoi contenuti non saranno embeddati altrove.
Questo header non è più in uso ed è preferibile utilizzare gli strumenti della CSP.
Conclusions
From our experience, we have found that activating very stringent headers involves on the one hand meeting the highest security parameters, often required by companies under analysis by external consultants, and on the other hand an investment of not insignificant resources and the technical skills of an operator who can dialogue with hosting support and any developers active on the project in order to meticulously choose the resources allowed.
Often rehashing projects with very stringent CSPs, perhaps adding a new plugin or functionality with active third parties, also involves additional intervention to the activated headers.
We therefore recommend a smart and elastic solution that is not too restrictive and goes hand in hand with constant monitoring systems such as WP Remote, the BlogVault platform that we use to monitor the security and performance status of websites under WP-HELP contract.
Questo contenuto è disponibile in Italiano
