Review the essential HTTP security headers every website should implement. Use the interactive checklist below to audit your site, learn what each header does, and get copy-paste configurations for your web server.
Check off the headers your site implements. Your score updates automatically.
HTTP security headers are instructions sent by a web server in the HTTP response that tell browsers how to handle the page content securely. They provide an additional layer of defense against common web attacks like cross-site scripting (XSS), clickjacking, and data injection. Implementing the right security headers is one of the easiest ways to improve your website's security posture.
These headers work alongside other security measures like strong encryption and DNS over HTTPS. While those protect network traffic, security headers protect the browser-server interaction itself. Whether you are running a website behind your router or on a hosting provider, security headers are essential.
These four headers are considered essential for any production website. Without them, your site is vulnerable to common attacks that could compromise your visitors:
| Header | Attack Prevented | Difficulty to Implement |
|---|---|---|
| Content-Security-Policy | XSS, injection, data theft | Medium-High (requires tuning) |
| Strict-Transport-Security | Protocol downgrade, cookie hijacking | Low (one line) |
| X-Content-Type-Options | MIME-type confusion attacks | Low (one line) |
| X-Frame-Options | Clickjacking | Low (one line) |
Pro Tip: Start with HSTS, X-Content-Type-Options, and X-Frame-Options — they are single-line additions that rarely break anything. Content-Security-Policy requires more careful testing because overly strict policies can break legitimate functionality. Always test CSP in report-only mode first using
Content-Security-Policy-Report-Only.
Here is how to add security headers in the most common web server configurations. These configurations are useful whether you are running a web server at home behind port forwarding or on a VPS:
# Add to server block or http context
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"// Using helmet middleware (recommended)
const helmet = require('helmet');
app.use(helmet());
// Or manually
app.use(function(req, res, next) {
res.setHeader('X-Content-Type-Options', 'nosniff');
res.setHeader('X-Frame-Options', 'DENY');
res.setHeader('Strict-Transport-Security', 'max-age=31536000');
next();
});CSP is the most powerful and complex security header. It defines which sources of content (scripts, styles, images, fonts, etc.) the browser should trust. A well-configured CSP can prevent most XSS attacks, even if an attacker finds a code injection vulnerability.
| CSP Directive | Controls | Common Values |
|---|---|---|
| default-src | Fallback for all resource types | 'self' |
| script-src | JavaScript sources | 'self' 'nonce-xxx' specific domains |
| style-src | CSS sources | 'self' 'unsafe-inline' (when needed) |
| img-src | Image sources | 'self' data: https: |
| connect-src | Fetch/XHR/WebSocket targets | 'self' api.example.com |
| frame-ancestors | Who can embed this page | 'none' (replaces X-Frame-Options) |
| form-action | Form submission targets | 'self' |
| upgrade-insecure-requests | Auto-upgrade HTTP to HTTPS | (no value needed) |
'unsafe-inline' for script-src or 'unsafe-eval' unless absolutely necessary — they defeat the purpose of CSP. Instead, use nonce-based or hash-based policies for inline scripts. If you must allow inline styles (common with many frameworks), restrict it to style-src only. For more information on web security concepts, see MDN's CSP documentation.
HTTP Strict Transport Security tells browsers to always use HTTPS when connecting to your domain. Once a browser sees the HSTS header, it will refuse to load the site over plain HTTP until the max-age expires. This prevents SSL stripping attacks and protocol downgrade attacks.
HSTS preloading goes further by hardcoding your domain in the browser's list of HTTPS-only sites. To qualify for the HSTS preload list, your header must include max-age of at least one year, includeSubDomains, and the preload directive.
This is particularly important if you are hosting services behind your port-forwarded router — without HSTS, an attacker on the same network could intercept the initial HTTP request before the redirect to HTTPS. Use our Port Checker to verify that only port 443 (HTTPS) is open, not port 80 (HTTP) without a redirect.
After implementing security headers, verify them using these methods:
# Open browser DevTools (F12)
# Go to Network tab
# Reload the page
# Click the main document request
# Check the Response Headers section# Using curl to check response headers
curl -I https://example.com
# Check specific header
curl -sI https://example.com | grep -i strict-transportOur DNS Lookup tool can also help verify that your domain resolves correctly before testing headers. For a complete security audit, combine header checks with port scanning and strong credential generation.
No. Security headers are tiny additions to the HTTP response (a few hundred bytes at most) and have zero impact on page load performance. They are parsed by the browser before any content renders, adding no measurable delay.
Content-Security-Policy is the main header that can cause issues if misconfigured, as it may block legitimate scripts, styles, or images. Start with CSP in report-only mode to identify what needs to be whitelisted. The other headers rarely cause problems.
The four critical headers (CSP, HSTS, X-Content-Type-Options, X-Frame-Options) should be on every production site. The others provide additional protection for specific attack vectors. Implementing all eleven gives you an A+ security rating on most auditing tools.
Yes. Even static HTML sites can be targeted by clickjacking, MIME-type attacks, and protocol downgrade attacks. Security headers protect your visitors regardless of whether your site has a backend. Most hosting providers and CDNs support custom headers.
Most CDNs (Cloudflare, AWS CloudFront, Fastly) allow you to add custom response headers through their dashboard or configuration. Cloudflare even has a managed security headers feature that adds recommended headers automatically.
The X-XSS-Protection header is deprecated in modern browsers (Chrome removed its XSS Auditor in 2019). However, including it does not hurt and provides protection for users on older browsers. It should not be your primary XSS defense — use Content-Security-Policy instead.
CSP controls what resources a page can load (client-side enforcement). CORS controls what origins can access a server's resources (server-side enforcement). They protect different aspects of web security and should both be configured. See our CORS Header Checker for more on CORS configuration.
About Tommy N.
Tommy is the founder of RouterHax and a network engineer with 10+ years of experience in home and enterprise networking. He specializes in router configuration, WiFi optimization, and network security. When not writing guides, he's testing the latest mesh WiFi systems and helping readers troubleshoot their home networks.
 |
 |
 |
 |
Promotion for FREE Gifts. Moreover, Free Items here. Disable Ad Blocker to get them all.
Once done, hit any button as below
|
|
|
|