If you want to harden a site against common web attacks, security headers are one of the fastest and most effective places to start.
This guide explains how to add security headers to a website, which headers matter most, and how to test them safely in production.
What security headers do
Security headers are HTTP response headers that tell the browser how to behave when loading your pages and assets.
They can reduce the risk of cross-site scripting, clickjacking, mixed content, data leakage, and unsafe resource loading.
Unlike application code changes, headers work at the browser layer, which makes them a valuable control for WordPress, custom applications, static sites, and APIs.
They are not a replacement for secure coding, but they add an important defensive layer.
Why security headers matter for SEO and trust
Search engines do not rank pages directly because they have security headers, but safer sites tend to have fewer compromises, less spam injection, and better user trust signals.
A site that loads securely is also less likely to trigger browser warnings that can hurt engagement.
For businesses, headers can support compliance and lower incident risk.
For developers, they are a low-cost way to improve the security posture of every response served by the application or CDN.
Core security headers to implement first
Not every header is required for every site, but these are the most widely recommended starting points.
Content-Security-Policy
Content-Security-Policy, often abbreviated CSP, is the most powerful browser security header.
It restricts where scripts, styles, images, fonts, frames, and other resources can load from.
A well-designed CSP can reduce the impact of cross-site scripting and malicious injection.
Start with a report-only policy if your site is complex, then tighten it once you know which sources are truly required.
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
Strict-Transport-Security
Strict-Transport-Security, or HSTS, forces browsers to use HTTPS for future visits.
Once a browser receives this header, it will refuse insecure HTTP connections for the specified time period.
This is especially useful after you have fully redirected and verified HTTPS across the site.
A typical starting value is one year.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options
X-Frame-Options helps prevent clickjacking by controlling whether your pages can be embedded in frames or iframes.
Modern CSP directives such as frame-ancestors are more flexible, but this header still has value for compatibility.
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options
X-Content-Type-Options prevents browsers from MIME-sniffing a response and interpreting it as a different type.
This reduces the chance that an uploaded or served file gets treated as executable content unexpectedly.
X-Content-Type-Options: nosniff
Referrer-Policy
Referrer-Policy controls how much URL information is sent in the Referer header when users click away from your site.
A stricter policy can help limit leakage of sensitive paths and query strings.
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy
Permissions-Policy lets you disable or restrict browser features such as camera, microphone, geolocation, and payment APIs.
This is useful for reducing exposure to unnecessary device capabilities.
Permissions-Policy: camera=(), microphone=(), geolocation=()
How to add security headers to a website on common platforms
The exact method depends on your server stack, CDN, or hosting provider.
In most cases, you can configure headers at the web server, application framework, or edge layer.
Apache
On Apache, headers are often added in the virtual host configuration or in an .htaccess file if overrides are allowed.
The mod_headers module must be enabled.
<IfModule mod_headers.c> Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN" Header always set Referrer-Policy "strict-origin-when-cross-origin" </IfModule>
For CSP and HSTS, place the directives carefully and test them before deployment because incorrect policies can break scripts or asset loading.
Nginx
On Nginx, security headers are usually added inside the server block or location block.
This method is common for sites behind reverse proxies and load balancers.
add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options SAMEORIGIN always; add_header Referrer-Policy strict-origin-when-cross-origin always;
Use the always parameter so headers are present on error responses as well, not just on successful requests.
Node.js and Express
In Express applications, the helmet package is a standard way to apply many common security headers with sensible defaults.
You can also configure individual headers manually when needed.
const helmet = require('helmet');
app.use(helmet());
Helmet helps reduce setup time, but you should still review the defaults and tailor CSP to the resources your site actually uses.
WordPress
For WordPress, headers are best added at the web server or CDN level so they apply consistently to all responses.
Security plugins can help, but server-level control is usually more reliable.
If you use managed hosting, check whether your provider supports custom response headers in its control panel.
If not, place the configuration in Apache, Nginx, or the edge platform serving the site.
CDN and edge platforms
Platforms such as Cloudflare, Fastly, and Akamai often allow header injection at the edge.
This can be ideal for static sites, global deployments, and applications where you want one central policy across multiple origins.
Edge-level headers are especially useful when origin servers are managed by different teams or when you need to protect cached responses consistently.
How to add security headers to a website without breaking it
The most common failure is deploying a strict policy before you know what the site depends on.
Start in observe mode when possible, then move to enforcement after review.
- Inventory scripts, styles, analytics tags, fonts, embeds, and third-party widgets.
- Use browser developer tools to identify blocked requests.
- Test on staging before pushing to production.
- Roll out one header at a time when troubleshooting.
- Keep a changelog for policy updates.
CSP deserves special care because it can block inline scripts, inline styles, and external resources unless they are explicitly allowed.
If your site uses a tag manager, inline event handlers, or legacy plugins, document those dependencies before locking down the policy.
How to verify your security headers
After configuration, confirm the headers are actually being sent.
Verification should happen both in the browser and from the command line.
- Use browser DevTools and inspect the Network tab.
- Run curl against the page URL and review response headers.
- Check multiple page types, including error pages and redirects.
- Validate headers on cached and uncached responses.
You can also use reputable testing tools such as securityheaders.com, Mozilla Observatory, or similar scanners to identify missing or misconfigured headers.
These tools are helpful, but they should supplement manual testing rather than replace it.
Common mistakes to avoid
Many teams implement security headers once and assume the job is done.
In practice, header policies need maintenance as the site evolves.
- Using a CSP that is too broad, such as allowing wildcard sources unnecessarily.
- Forgetting headers on redirects, 4xx responses, or 5xx responses.
- Setting HSTS before confirming the whole domain supports HTTPS.
- Relying only on client-side plugins when server-level control is available.
- Blocking required third-party services without documenting them first.
Another mistake is treating security headers as a checklist item without understanding the browser behavior they control.
The strongest results come from pairing them with secure authentication, input validation, least privilege, and routine dependency updates.
Best practices for maintaining security headers
Once your policy is live, review it whenever you add a new feature, integration, or third-party script.
Marketing pixels, analytics tools, payment widgets, and embedded media often require CSP updates.
Maintain a staging environment that mirrors production as closely as possible.
This makes it easier to catch policy conflicts before users do.
For larger organizations, store header settings in infrastructure-as-code or configuration management so changes are versioned and reviewable.
That approach makes audits easier and reduces drift across environments.
When to use a minimal versus strict policy
A minimal policy is often appropriate for small sites, brochure sites, and early deployments where you want immediate baseline protection.
A strict policy is better for applications with stable dependencies and strong testing practices.
If your site changes frequently, consider a phased approach: deploy baseline headers first, introduce CSP in report-only mode, then tighten directives as the false positives disappear.
This keeps the rollout controlled while still improving security quickly.