Your website has an SSL certificate, forms with anti-spam protection, and scheduled backups. But if you have never reviewed your HTTP security headers, you are still exposed to attacks browsers could block automatically: clickjacking, script injection, referrer leaks, or mixed content.
Security headers are instructions your server sends to the browser on every response. Visitors never see them, but they control how your site loads, which third-party resources can run, and what data is shared externally. In this guide we cover the essential headers for a business website, how to configure them without breaking analytics, maps, or widgets, and how to audit them before a real incident does.
What HTTP security headers are and why they matter
Every time someone visits your site, the server returns HTML, CSS, JavaScript, and images — plus HTTP headers. Some are technical (Content-Type, Cache-Control), but others are designed to reduce attack surface:
- They protect visitors from malicious scripts, hidden iframes, or unwanted redirects.
- They protect your brand by preventing your domain from being embedded in fraudulent pages.
- They complement SSL: HTTPS encrypts the connection; headers limit what content can do once downloaded.
- They build trust in security audits, tenders, or B2B due diligence.
They do not replace solid development or a web security plan, but they are a cheap, effective layer many corporate sites ignore.
Signs your website needs a header review
- You have never audited headers since the site went live.
- You use Google Tag Manager, maps, live chat, or reCAPTCHA and do not know if stricter policies will break them.
- Tools like Mozilla Observatory or SecurityHeaders.com score your domain F or D.
- You have seen injection attempts on forms or user-generated content.
- Your site is embedded in third-party iframes without control.
- After migrating hosting or CDN, rules from the old server stopped applying.
If two or more apply, schedule a review before your next traffic peak or lead-generation campaign.
Essential security headers for a business website
Strict-Transport-Security (HSTS)
Forces browsers to use HTTPS for a defined period. Prevents downgrade attacks and accidental http:// access. Enable only when HTTPS works correctly across the domain and relevant subdomains.
Content-Security-Policy (CSP)
The most powerful — and delicate — header. Defines which domains can load JavaScript, CSS, images, fonts, or iframes. A well-tuned CSP stops XSS; an overly strict one breaks Google Tag Manager, embedded videos, or contact maps.
X-Frame-Options / frame-ancestors
Prevents your site loading inside an iframe on another domain (clickjacking). Modern CSP uses frame-ancestors; keep both consistent.
X-Content-Type-Options: nosniff
Stops browsers interpreting files with a different MIME type than declared. Reduces risk with PDFs, SVGs, or misconfigured static files.
Referrer-Policy
Controls how much URL information is sent when navigating to external links. Useful to avoid leaking UTM parameters or internal paths.
Permissions-Policy
Restricts browser APIs (camera, microphone, geolocation, payments). On standard corporate sites, block everything except what you truly need.
How to implement headers without breaking your site
The most common mistake is enabling an aggressive CSP in production without testing. Follow this order:
- Audit current state with SecurityHeaders.com, observatory.mozilla.org, or browser DevTools (Network tab → response headers).
- Enable “safe” headers first:
X-Content-Type-Options,Referrer-Policy,Permissions-Policy, and HSTS (if HTTPS is stable). - Test CSP in report-only mode (
Content-Security-Policy-Report-Only) to see what would be blocked without affecting visitors. - List all third parties: analytics, ads, chat, fonts, image CDNs, YouTube/Vimeo, reCAPTCHA.
- Switch to enforced CSP with minimum directives:
default-src,script-src,style-src,img-src,font-src,connect-src,frame-src. - Verify forms, checkout, and private areas after each change.
Document configuration in your repo or provider wiki. When you change CDN or plugins, review headers again.
Where to configure headers depending on your stack
- Apache (.htaccess or VirtualHost):
Header setwith mod_headers. - Nginx:
add_headerin server or location blocks. - Cloudflare or CDN: Transform Rules or Workers when you do not control origin.
- Laravel / frameworks: custom middleware for route-specific headers.
- WordPress: security plugins or hosting config; beware duplicate headers.
If a CDN sits in front of origin, ensure headers reach the browser and are not overwritten.
Common mistakes on business websites
- HSTS without stable HTTPS: locks users out if mixed content or certificates fail.
- CSP copied from a generic tutorial: breaks GTM, Typekit, HubSpot, or WhatsApp widgets.
- Duplicate or conflicting headers between CDN, proxy, and origin.
- Not testing on staging before production.
- Confusing security with privacy: headers do not replace cookie banners and GDPR.
- Forgetting subdomains:
www,blog,staging, or campaign landings may stay unprotected.
Security headers, monitoring, and maintenance
Headers are not set once and forgotten. Plugin changes, new marketing scripts, or migrations can invalidate a working CSP. Include reviews in your monitoring routine and maintenance plan:
- Quarterly score checks on public tools.
- Alerts if HSTS or CSP disappears after a deploy.
- Change log when adding a new third-party script.
A site that breaks because a misconfigured CSP blocks mobile menu JavaScript is as damaging as a server timeout.
Conclusion
HTTP security headers separate a site that “has HTTPS” from one ready to withstand automated attacks and demanding client reviews. Start with low-risk headers, test CSP in report-only mode, and document every exception for legitimate scripts.
At aatsoft, a web development agency in Manresa (Barcelona), we audit headers, CSP, and server configuration on new projects and live sites. If you have never reviewed your domain headers, now is the time — before an incident forces you to.
