Installing an SSL certificate is a crucial first step for website security, but it does not completely shield visitors from sophisticated network threats. Without proper server configuration, browsers can still attempt initial connections over plain HTTP, leaving your site vulnerable to protocol downgrade attacks and cookie hijacking. To solve this, web administrators use a response header policy known as HSTS.
HTTP Strict Transport Security forces web browsers to interact with your server exclusively through secure HTTPS connections. When a browser receives the HSTS header, it remembers to automatically convert any future internal http:// links into https:// requests before sending data. This guide explains how to configure this essential security measure correctly on popular web servers.
How to Implement HTTP Strict Transport Security: Understand How HSTS Works and Its Core Directives
Before modifying your server files, it helps to understand how the HSTS response header is structured. A standard HSTS header includes a max-age directive, which tells the browser how long it should remember to enforce secure connections only. Optional directives include includeSubDomains, which applies the rule to all subdomains, and preload, which signals readiness for browser inclusion lists.
An example configuration header looks like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Setting a short max-age initially, such as five minutes or one day, is recommended when testing changes. Once you confirm that all assets, images, and external links load correctly over HTTPS without mixed-content errors, you can safely increase the max-age value to one year or longer.
Step 1: Configure HSTS on Nginx Servers
For websites running on Nginx, all server-level configurations must be handled by an administrator since content management systems cannot alter server block rules directly, as noted in the Nginx Advanced Administration Handbook. Open your server block configuration file using a text editor.
Locate your server block configuration for port 443 and add the add_header directive inside the SSL server context:
server {
listen 443 ssl;
server_name example.com;
# SSL certificate paths here
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}
Save the file and test your syntax by running nginx -t in your terminal. If the test succeeds, reload your Nginx service to apply the new header.
Step 2: Configure HSTS on Apache Servers
Websites hosted on Apache servers can apply headers through main configuration files or local .htaccess rules, aligning with guidelines in the Apache HTTPD Handbook. Ensure that the Apache headers module is enabled on your server environment before adding rules.
Add the following snippet to your VirtualHost configuration or your root .htaccess file:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
Save your changes and restart or reload your Apache service to ensure the header is served on all outbound HTTPS responses.
Step 3: Submit Your Domain to the HSTS Preload List
For maximum protection, you can submit your domain to the official HSTS preload list maintained by browser vendors. Preloading hardcodes your domain into browsers so that even the very first visit is forced over HTTPS.
Before submitting your domain, ensure you meet all requirements:
- Valid SSL certificate with zero certificate warnings.
- Redirect all HTTP traffic to HTTPS on the same host.
- Serve the HSTS header on all subdomains if includeSubDomains is used.
- Set a max-age of at least 31536000 seconds (one year).
Once these requirements are met, enter your domain into the official HSTS preload submission tool. Keep in mind that removal from the preload list can take months once approved, so test your infrastructure thoroughly beforehand.
Conclusion
Implementing HTTP Strict Transport Security closes a critical gap in web transport layer security by eliminating plaintext fallback risks. By configuring the header correctly on Apache or Nginx and verifying your assets, you can significantly strengthen your site protection against man-in-the-middle attacks.
Frequently Asked Questions
What Happens If I Enable HSTS Before My Website Is Fully Ready for HTTPS?
If you enable HSTS while your site still contains mixed content or broken HTTP links, visitors may be blocked from accessing your website entirely until the max-age timer expires or they clear their browser cache.
Can I Enable HSTS Directly from the WordPress Dashboard?
No. WordPress cannot modify core server block configurations or strict transport security headers directly. Configuration must be handled at the web server level using Apache or Nginx settings, or via a trusted security plugin that manages server response headers.
What Is the Recommended Initial Max-age Value When Testing HSTS?
It is recommended to start with a short max-age value, such as 300 seconds (5 minutes) or 86400 seconds (1 day). This allows you to safely test for broken assets or configuration errors without locking users out for a long period.
Is It Possible to Reverse a Submission to the HSTS Preload List?
Removing a domain from the browser preload list requires submitting a removal request and waiting for browser vendors to push software updates, which can take several months. You should only preload your domain after months of stable HSTS header deployment.


