This article is a sample from an e-book sold on this website, whose first edition is available in Portuguese language, and licensed under CC BY-NC 4.0.
HTTP Security Headers are a type of instruction sent by a server to guide a browser on how to handle the content of a given website securely – acting as a fundamental layer of defense against client-side attacks. They are very simple and lightweight to implement, and therefore highly recommended. These headers can also be called HTTP response headers, browser security directives, or website security enhancement headers.
Implementing security headers is one of the essential security measures listed in any guide on the subject, in the context of self-hosted websites, and it does not apply to fully managed hosting environments (like WordPress.com).
There are many security headers and no less numerous configuration combinations, which depend heavily on each website and its characteristics.
The correct and secure implementation of HTTP security headers can be very simple and quick on websites built on other architectures, but in WordPress it ends up going far beyond an intermediate level of learning, mainly because of this header – Content-Security-Policy – designed to prevent Cross-Site Scripting (XSS), Clickjacking, and code injection attacks by defining permitted sources for content (e.g., scripts, styles, images, etc.). Since WordPress is a CMS framework, it immediately implies a wide range of content sources, with particular emphasis on scripts and dynamic CSS generated at runtime – which makes them difficult to define.
Depending on the characteristics of each site, a CSP in this context can involve a wide range of values in the directives, encouraging the abandonment of its implementation, as poorly configured, incomplete or outdated directives result in the blocking of content and functionalities, including the website’s layout itself, and even parts of the backend.
One way to configure a CSP for WordPress is to use a more specific plugin, an online generator service, or a browser extension installed for this purpose. These applications analyze the website in real time, over a certain period (hours, days, or weeks), and collect the configuration detected as necessary. The result obtained usually includes critical directive values that are completely inadvisable, which can then be resolved by alternative methods, but not always. The choice of plugins and themes that favor a secure CSP can also be a determining factor here, but it is very difficult to apply in practice, making it common to opt for simply mitigating an insecure CSP through the secure configuration of other headers, a good firewall, the use of canary tokens, and other reinforcements.
Depending on the size and category of the websites, a successful and secure CSP in WordPress may also require continuous monitoring, considering the updates involved in the core, plugins, and themes, leading to the need for a dedicated CSP service.
Here’s an example of a very basic CSP configuration for implementation on an Apache server, by editing the .htaccess file (for the vast majority of websites hosted on shared server setups).
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://xxxxxx.com"
