{"id":7711,"date":"2023-11-22T11:04:28","date_gmt":"2023-11-22T10:04:28","guid":{"rendered":"https:\/\/f.technology\/blog\/wordpress-en\/enhancing-security-with-http-security-headers\/"},"modified":"2023-11-22T11:04:28","modified_gmt":"2023-11-22T10:04:28","slug":"enhancing-security-with-http-security-headers","status":"publish","type":"post","link":"https:\/\/f.technology\/en\/blog\/cyber-security-en\/enhancing-security-with-http-security-headers\/","title":{"rendered":"Enhancing Security with HTTP Security Headers"},"content":{"rendered":"

Why are HTTP Security Headers important and what are they?<\/h2>\n

We might think of HTTP Security Headers<\/strong> as something extremely technical.
\nIn 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.
\nPut 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<\/a>, which is an overall evaluation of the various elements that make up the user experience.
\nInside we also find Core Web Vitals, optimization for mobile, the presence of HTTPS and, indeed, web page security.
\nHTTP Security Headers are directives, related to the security of the website, that are transmitted through theHTTP header<\/a> response, which is the response that the web server gives to the browser software that is trying to access the website.
\nThe client, the program you use to browse, connects to your web space through a domain and receives various information.
\nSuch as the status code (200 if okay, 404 if bad).
\nHTTP Security Headers related security headers define limits and instructions that prevent unwanted and dangerous actions to your work published on the Internet.
\nThese elements are responsible for defining an advanced level of security.
\nBy 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.
\nSure, you can work on other fronts as well, such as using plugins to increase security and mounting a good firewall or using quality hosting.
\nBut that’s not always enough, which is why HTTP Security Headers come into play.
\nLet’s look together at the main guidelines you can use: <\/p>\n

Strict Transport Security (HSTS) – restrictive security on the HTTP transport<\/h3>\n

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.
\nThis is more secure than a common 301 redirect, which would allowman-in-the-middle<\/a> attacks.
\nThrough parameters, it is possible to set the maximum time for browsers to store the setting, as well as the application to subdomains.
\nExample: Strict-Transport-Security: max-age=31536000 ; includeSubDomains<\/em><\/p>\n

Content Security Policy (CSP) – Content Security Policy<\/h3>\n

This solution is designed to anticipate and defuse a wide range of attacks, including cross-site scripting<\/a> that uses a vulnerability in website security.
\nThrough such levity, such as using unsafe plugins or not updating WordPress themes<\/strong>, 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).
\nThe 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!
\nThis 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.
\nAlso 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.
\nFor example, to enable nonce-based strict CSP<\/a> you will have to edit callbacks to all dependencies used by the website, and that is not always trivial.
\nOn 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.
\nTwo opposing methods that require major interventions to HTML templates and dependency inclusions.
\nAn example directive: Content-Security-Policy: font-src font.example.com;<\/em><\/p>\n

X-Content-Type-Options<\/h3>\n

This header is used by the server to signal that the MIME<\/a> types specified for the various content published on the page (images, files, Javascript, etc.) must be respected and not changed.
\nThis avoids misinterpretation of files<\/strong>: this would become crucial if a malicious file is masked as a different file type, exploiting the MIME type sniffing<\/a> 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.
\nIt is triggered by the directive: X-Content-Type-Options: nosniff<\/em><\/p>\n

Referrer Policy – Policy on Referrer<\/h3>\n

This directive determines what information is passed to the landing site of a link placed on your Web site whenever you leave a page.
\nVarious options are available based on protocol (HTTP or HTTPS) and site (whether the same or another).
\nThe purpose of a Referrer-Policy header is to control what information is sent when a visitor leaves your pages to visit another portal.
\nThe default is to send domain, path and query string if you stay on the same site.
\nFor outbound queries you send the domain in case you stay on HTTPS.
\nNo data is sent should you switch to HTTP.
\nWith the no-referrer command the header will be omitted altogether, example: Referrer-Policy: no-referrer<\/em><\/p>\n

Clear Site Data (CSD)<\/h3>\n

The Clear-Site-Data parameter clears browsing data (cookie type, cache) related to the website.
\nIt allows webmasters to have more control over the information stored by a browsing browser.
\nThis header is useful during a logout process, for example, it ensures that all content stored on the browser is removed.
\nIn 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.
\nExample: Clear-Site-Data: “cache”, “cookies”, “storage”<\/em><\/p>\n

Permissions Policy<\/h3>\n

Permissions Policy provides mechanisms that allow developers to explicitly declare what functionality can and cannot be used on a site.
\nIt 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.
\nPermissions Policy is similar to CSP but controls functionality instead of security behavior.
\nExamples of what you can do with Permissions Policy: <\/p>\n