Security headers help protect websites from common attacks such as clickjacking, MIME-type sniffing, cross-site scripting (XSS), and unauthorized access to sensitive browser features. If you’re using Apache, many of these protections can be configured directly in your .htaccess file.
Why Security Headers Matter
Security headers instruct browsers how to handle your website’s content and interactions. While they are not a substitute for secure coding practices, they provide an additional layer of defense.
Properly configured headers can help:
- Reduce certain XSS risks
- Prevent clickjacking attacks
- Stop MIME-type sniffing
- Improve HTTPS security
- Control browser feature access
- Reduce information leakage
Basic Security Headers Configuration
A commonly used set of security headers for Apache looks like this:
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set X-XSS-Protection "1; mode=block"
</IfModule>
Before using these headers, ensure the Apache mod_headers module is enabled.
X-Frame-Options
This header helps protect against clickjacking attacks by controlling whether your pages can be displayed inside frames or iframes.
Common values include:
DENY – Prevents all framingSAMEORIGIN – Allows framing only from the same site
For most websites, SAMEORIGIN is a practical choice.
X-Content-Type-Options
Browsers sometimes attempt to guess a file’s content type. This behavior can create security risks.
The following header disables MIME-type sniffing:
Header always set X-Content-Type-Options "nosniff"
This helps ensure files are treated according to their declared content type.
Referrer-Policy
The Referrer Policy controls how much referral information is sent when users navigate to another website.
A commonly recommended setting is:
Header always set Referrer-Policy "strict-origin-when-cross-origin"
This balances privacy and analytics needs.
Permissions-Policy
Permissions Policy allows websites to restrict access to browser features that may not be needed.
For example:
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
This prevents those features from being used unless explicitly allowed.
Content-Security-Policy (CSP)
Content Security Policy is one of the most powerful security headers available. It helps control which resources browsers are allowed to load.
A basic example is:
Header always set Content-Security-Policy "default-src 'self';"
However, CSP should be carefully tested because an overly restrictive policy can break website functionality.
For sites using external resources such as CDNs, fonts, analytics, or advertising scripts, a custom policy is usually required.
Strict-Transport-Security (HSTS)
If your website uses HTTPS exclusively, HSTS instructs browsers to always connect securely.
Example:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
This should only be enabled after confirming that HTTPS works correctly across the entire site and all subdomains.
Removing Server Information
Some administrators choose to reduce information disclosure by hiding certain server details.
For example:
ServerSignature Off
Combined with Apache configuration settings, this can reduce the amount of information exposed to visitors and automated scanners.
A Practical Security Header Set
For many modern HTTPS websites, a reasonable starting point is:
<IfModule mod_headers.c>
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set Content-Security-Policy "default-src 'self';"
</IfModule>
Before deploying these headers to a production environment, test your website thoroughly to ensure all functionality, third-party services, fonts, scripts, and media continue to work correctly.
Common Mistakes
Security headers are most effective when configured carefully. Problems often occur when settings are copied without testing.
Common issues include:
- Overly restrictive CSP rules
- Enabling HSTS before HTTPS is fully configured
- Using conflicting header values
- Blocking required third-party resources
- Forgetting to enable
mod_headers
- Applying policies that break embedded content
Join The Discussion
Which security headers do you consider essential for modern websites? Have you implemented Content Security Policy, HSTS, or Permissions Policy on your site, and what challenges did you encounter? Share your configurations, lessons learned, troubleshooting tips, and best practices for improving website security with HTTP response headers.
