HTTP Security Headers in WordPress: Implementing HSTS, CSP and More – Step by Step

WordPress Secure as a Fortress? Start with the Invisible Guards – HTTP Headers!

Every WordPress site owner wants their website to be not only fast and functional, but above all secure. In an era of growing cyber threats, simply having a strong password and up-to-date software is often not enough. However, there is a powerful yet often underestimated tool that significantly raises the level of protection: HTTP security headers. In this article, we will walk you through the key headers such as HSTS, CSP, Permissions Policy and others, explaining how they work and how you can implement them on your WordPress site, including with the help of the Headers Security Advanced & HSTS WP plugin.

What Are HTTP Security Headers and Why Should You Know About Them?

HTTP headers are instructions sent by the server to the user’s web browser with every page request. In addition to content information, they can contain security directives. HTTP security headers instruct the browser on how to behave in order to minimise the risk of common attacks such as Cross-Site Scripting (XSS), clickjacking and man-in-the-middle attacks. Properly configured, they become the first line of defence for your website.

Key Security Headers You Must Know (and Implement!)

Let us look at the most important headers that will help secure your WordPress site:

1. HTTP Strict Transport Security (HSTS) – Strict-Transport-Security

• What does it do? This header tells the browser that it should only communicate with your site over a secure HTTPS connection, not HTTP. If a user or a link tries to connect via HTTP, the browser will automatically redirect to HTTPS before any data is transmitted.
• Benefits: Protects against SSL stripping attacks (an attempt to downgrade the connection to unsecured HTTP) and man-in-the-middle attacks during the first, potentially unencrypted visit.
• Key directives:
  • max-age: The time (in seconds) for which the browser should remember to use HSTS for this domain (e.g. max-age=31536000 for one year).
  • includeSubDomains: Extends HSTS to all subdomains.
  • preload: Allows your domain to be added to the global “HSTS preload list” built into browsers, meaning even the first visit will be forced over HTTPS. (Requires caution and full HTTPS operation across the entire domain and subdomains, as well as prior setting of max-age to at least one year and includeSubDomains.)

2. Content Security Policy (CSP) – Content-Security-Policy

• What does it do? This is one of the most powerful but also most complex headers. It allows you to control which sources the browser may load resources from (scripts, styles, images, fonts, iframes etc.). You create a “whitelist” of allowed domains and resource types.
• Benefits: Drastically reduces the risk of XSS (Cross-Site Scripting) attacks by preventing malicious scripts from loading from unauthorised sources. It can also protect against data injection.
• Key directives (examples):
  • default-src ‘self’: By default, only allows resources to be loaded from the same domain.
  • script-src ‘self’ https://cdn.example.com: Allows scripts from your own domain and cdn.example.com.
  • style-src ‘self’ ‘unsafe-inline’ https://fonts.googleapis.com: Allows styles from your own domain, inline (caution – risk!) and from Google Fonts.
  • img-src ‘self’ data: Allows images from your own domain and base64-encoded images.
  • frame-ancestors ‘self’: Allows the page to be embedded only within the same domain.
• WARNING: Incorrect CSP configuration can completely break your site or its key functions! This is a powerful tool, but it requires careful planning and testing. Always start with the Content-Security-Policy-Report-Only directive. This version of the header does not block resources — it only sends violation reports to a specified address (using the report-uri or newer report-to directive). Only after thoroughly analysing the reports and confirming that the policy is correct and does not block legitimate resources should you switch to Content-Security-Policy.

3. Permissions Policy (formerly Feature Policy) – Permissions-Policy

• What does it do? Allows you to control which browser features (such as access to the camera, microphone, geolocation, full screen etc.) can be used by your page and content embedded within it (e.g. iframes).
• Benefits: Enhances user privacy and prevents abuse of browser features by malicious scripts or unwanted third-party content.
• Example directives: camera=(), microphone=(), geolocation=(self “https://yourdomain.com”). The value () means the feature is completely disabled.

4. X-Content-Type-Options – X-Content-Type-Options

• What does it do? With the single value nosniff, this header prevents so-called “MIME-sniffing” — the browser’s attempt to guess the file type regardless of the declared Content-Type.
• Benefits: Protects against attacks where a malicious file (e.g. a script) is disguised as another file type (e.g. an image). If the browser “guesses” differently from what the server declared, it could execute malicious code.

5. X-Frame-Options – X-Frame-Options

• What does it do? Controls whether your page can be embedded in an iframe, frame, embed or object element on other websites.
• Benefits: Effectively protects against clickjacking attacks, where a user is tricked into clicking on something other than they think, by overlaying an invisible frame with malicious content on a legitimate page.
• Possible values:
  • DENY: Completely forbids embedding.
  • SAMEORIGIN: Allows embedding only within the same domain.
  • ALLOW-FROM uri: (Older, less supported) Allows embedding from a specific URI. (CSP frame-ancestors is the modern and more recommended alternative.)

Why Are These Headers Crucial for Your WordPress Site?

• Enhanced Security: The obvious benefit. You minimise the attack surface and protect against many common vectors.
• User Data Protection: You safeguard your customers’ and users’ data from leakage or theft.
• Building Trust: Users (and browsers) increasingly appreciate sites that take security seriously (e.g. the HTTPS indicator).
• Potential SEO Improvement (indirectly): Google values secure sites. While the headers themselves are not a direct ranking factor, the overall quality and security of a website do matter.
• Compliance with Best Practices: You demonstrate that your site is built and managed professionally.

How to Implement HTTP Security Headers in WordPress?

Although headers can be added manually by editing server files or PHP code, for most WordPress users the simplest and safest approach is to use a dedicated plugin.

Method 1: Plugins – Recommended Solution (e.g. Headers Security Advanced & HSTS WP)

Plugins such as Headers Security Advanced & HSTS WP by Andrea Ferro simplify the configuration of these headers.

• How do they work? They typically offer a user interface where you can enable/disable individual headers and configure their directives without needing to edit code.
• Headers Security Advanced & HSTS WP: This specific plugin allows easy management of HSTS, CSP, X-Frame-Options, X-Content-Type-Options and others, offering ready-made presets or the option for more advanced configuration.
• Other plugins: There are also other security plugins (e.g. Sucuri Security, Wordfence — some in premium versions offer header management) or more specialised plugins focused solely on headers.

Method 2: Manual Configuration (for Advanced Users)

• .htaccess file (for Apache/LiteSpeed servers):

If you prefer manual implementation and have the necessary technical knowledge, you can configure headers directly.

<IfModule mod_headers.c>
    # HSTS (Remember: full HTTPS and testing required before preload)
    # Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"

    # Content-Security-Policy (simplified example)
    # Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscripts.example.com; style-src 'self' https://fonts.googleapis.com;"
</IfModule>

Important: CSP configuration in .htaccess must be very precise. Incorrect directives can block key resources from loading. Always test!

• Server configuration file (e.g. nginx.conf for Nginx):

# HSTS (Remember: full HTTPS and testing required before `preload`)
# Only set if the entire site runs on HTTPS
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# X-Frame-Options
add_header X-Frame-Options "SAMEORIGIN" always;

# X-Content-Type-Options
add_header X-Content-Type-Options "nosniff" always;

# Content-Security-Policy (VERY SIMPLIFIED EXAMPLE - requires careful customisation!)
# ALWAYS START WITH Content-Security-Policy-Report-Only
# add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscripts.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; object-src 'none'; frame-ancestors 'none';" always;

Important: Remember to reload the Nginx configuration after making changes (sudo nginx -s reload).

• Child theme functions.php file (WordPress):

<?php
function dosgatos_add_security_headers() {
    // HSTS (Remember: full HTTPS and testing required before `preload`)
    // Only set if the entire site runs on HTTPS
    // if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') {
    //     header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
    // }

    // X-Frame-Options
    header('X-Frame-Options: SAMEORIGIN');

    // X-Content-Type-Options
    header('X-Content-Type-Options: nosniff');

    // Content-Security-Policy (VERY SIMPLIFIED EXAMPLE - requires careful customisation!)
    // ALWAYS START WITH Content-Security-Policy-Report-Only
    // header("Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; object-src 'none'; frame-ancestors 'none';");
}
add_action('send_headers', 'dosgatos_add_security_headers');
?>

Note: Adding headers via PHP is less efficient than at the server level and may be overridden by some plugins or server configurations. This approach is generally the least recommended for security headers.

Diagnostics and Testing of Security Headers – Check Your Shield!

After implementing security headers, it is crucial to verify that they work correctly and do not block legitimate functions of your site. Here are some useful tools:

• Security Headers (Netsparker): A simple online tool that scans your site and rates the security header configuration, pointing out gaps and errors.
• Mozilla Observatory: A more advanced tool from Mozilla that analyses many security aspects of a website, including HTTP headers, and offers detailed recommendations.
• Google CSP Evaluator: An indispensable tool for analysing and debugging your Content Security Policy. It helps identify potential issues and gaps in your CSP configuration.
• Browser developer tools: The “Network” tab in developer tools (accessible by pressing F12 in most browsers) lets you see all headers sent by the server for each request. The JavaScript console will show errors related to CSP violations (e.g. blocked scripts or styles).

Important Notes and Best Practices When Implementing Headers

• Test, Test, Test! Especially with CSP, an incorrect configuration can completely break your site or its key features. Always test on a development environment or a copy of the site before deploying to production.
• Start slowly: Implement headers one at a time, carefully verifying that everything works correctly on all key subpages.
• Understand what you are doing: Do not blindly copy configurations from the internet. Understand what each directive means and how it affects your specific WordPress site, its theme and the plugins you use.
• CSP: Always start with Content-Security-Policy-Report-Only. This mode allows you to collect violation reports without blocking anything. Analyse these reports (e.g. using a service such as report-uri.com or your own endpoint) and refine the policy before switching to the blocking mode (Content-Security-Policy). This is a critical step to avoid “breaking” your site.
• HSTS Preload with caution: Adding your domain to the HSTS preload list is a major commitment. Make sure your entire website (including subdomains if you use includeSubDomains) is 100% on HTTPS and that you plan to keep it that way permanently. Removal from the list is a time-consuming and not always straightforward process.
• Regular review: Security requirements and plugin/theme configurations can change over time. It is worth reviewing header settings periodically and re-testing their effectiveness, especially after major site updates.

Summary: HTTP Headers – Your Invisible Heroes of WordPress Security

Implementing HTTP security headers is an important step towards making your WordPress site more resilient to attacks. While some of them, like CSP, may seem complex at first, the benefits of using them are invaluable. Remember that tools such as the Headers Security Advanced & HSTS WordPress plugin can greatly simplify this process, but the key is understanding how they work and carrying out thorough, systematic testing.

At DosGatos.RED, we attach great importance to the security of our clients’ websites. If you need help implementing security headers, optimising your site (e.g. images) or conducting a comprehensive security audit of your WordPress site, feel free to contact us!

Frequently Asked Questions (FAQ) – Security Headers in WordPress