Add Security Headers in cPanel: CSP, HSTS, X-Frame-Options
You ran your site through securityheaders.com or Mozilla Observatory and got a C or D grade. No Content-Security-Policy, no HSTS, no X-Frame-Options. Nothing is actually broken, but a client, an auditor, or your own conscience wants those headers in place. Here's how to add them through cPanel without taking the site down in the process.
Symptom: missing or weak security headers
You'll usually find this one of three ways:
- A third-party scanner (securityheaders.com, Mozilla Observatory, Qualys SSL Labs) grades the site low and lists headers as "missing."
- A pentest or compliance review (PCI-DSS, SOC 2, a client's security team) flags the absence of CSP, HSTS, or clickjacking protection.
- Someone notices the site can be loaded inside an
<iframe>on another domain, or the browser console shows no CSP violations because there's no policy to violate in the first place.
None of this is an outage. It's exposure: clickjacking, MIME-sniffing attacks, protocol downgrade on repeat visits, and weaker defense-in-depth if an XSS bug ever slips through your code.
Cause: Apache and LiteSpeed don't add these by default
Security headers aren't something cPanel, Apache, or LiteSpeed sends automatically. They have to be explicitly configured, almost always through mod_headers in your .htaccess file (LiteSpeed's Apache-compatible mode honors the same directives, so this works whether your account runs Apache or LiteSpeed under the hood). Most site builders and WordPress installs never touch this file for headers, so the response just goes out with whatever the browser's defaults assume — which is not much.
Fix: add the headers via .htaccess
Log in to cPanel → File Manager → open your site's document root (usually public_html or public_html/yourdomain.com for an addon domain) → edit .htaccess. Make sure Show Hidden Files is enabled in File Manager settings, since dotfiles are hidden by default.
Add this block near the top of the file, above any WordPress or rewrite rules:
<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"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>Save the file, then confirm the headers are actually going out:
curl -I https://yourdomain.comYou should see each header listed in the response. If you don't, check that mod_headers is enabled — on shared cPanel hosting it almost always is, but if you're on a VPS running your own Apache stack, verify with apache2ctl -M | grep headers and enable it with a2enmod headers if missing.
What each header actually does
| Header | What it protects against | Safe starting value |
|---|---|---|
| X-Content-Type-Options | MIME-sniffing attacks (browser guessing a script is an image, or vice versa) | nosniff |
| X-Frame-Options | Clickjacking — your site loaded in a hidden iframe on someone else's page | SAMEORIGIN |
| Referrer-Policy | Leaking full URLs (including query strings/tokens) to third-party sites via the Referer header | strict-origin-when-cross-origin |
| Permissions-Policy | Pages you embed (ads, widgets) silently using camera, mic, or location | Deny what you don't use |
| Strict-Transport-Security | Downgrade to HTTP on a repeat visit, and SSL-stripping attacks on public Wi-Fi | max-age=31536000; includeSubDomains |
| Content-Security-Policy | XSS — restricts which scripts, styles, and frames the browser will actually execute | Start in report-only mode (below) |
The one that actually breaks things: Content-Security-Policy
CSP is the header with real teeth, and it's also the one that will break your Google Analytics, your payment gateway iframe, your Google Fonts, or your inline <script> tags if you paste in a strict policy without testing first. Don't add a live Content-Security-Policy header on a production site as your first move. Add it in report-only mode instead:
Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com"In report-only mode, the browser evaluates the policy and logs violations to the console (or to a report-uri endpoint if you set one), but nothing is actually blocked. Load every page type — homepage, checkout, contact form, any embedded widget — and check the browser console for Content-Security-Policy-Report-Only violations. Add each legitimate domain to the relevant directive, then switch Content-Security-Policy-Report-Only to Content-Security-Policy once it's clean for a few days.
If you're behind Cloudflare
You can set the same headers at the edge via Cloudflare's Transform Rules (Rules → Transform Rules → Modify Response Header) instead of, or in addition to, .htaccess. If you set them in both places, Cloudflare's edge headers usually win for cached responses — don't debug a "header not appearing" issue for an hour before checking your Cloudflare dashboard for a conflicting rule.
Prevention
- Re-run the scanner (securityheaders.com or Mozilla Observatory) after every change — don't assume the syntax was right.
- Keep a copy of your
.htaccessblock somewhere outside the server. A bad WordPress plugin update or a careless File Manager edit can wipe custom directives. - When you add a new third-party script — a chat widget, a new ad network, a booking iframe — check it against your CSP before it goes live, not after a client reports a broken checkout.
- Don't set
X-Frame-Options: DENYif you legitimately embed your own site in an iframe elsewhere (a widget, a preview tool). UseSAMEORIGINor the CSPframe-ancestorsdirective for finer control.
Frequently asked questions
Will adding security headers slow down my site?
No. Headers add a negligible number of bytes to each response — there's no measurable performance cost. The only risk is functional, not speed: a misconfigured CSP can block scripts or fonts from loading.
Do I need mod_security or WAF rules for this, or is .htaccess enough?
Security headers and a WAF (like ModSecurity) solve different problems. Headers tell the browser how to behave; a WAF filters malicious requests before they reach your app. You want both, but headers alone via .htaccess are enough to fix a low security-headers scan grade.
My WordPress site already has a security plugin — do I still need this?
Check first. Plugins like Wordfence or iThemes Security can add some of these headers, and if they do, adding your own .htaccess block on top can create duplicate or conflicting headers. Run curl -I against your site to see what's already being sent before adding anything.
Can this break my site if I get the syntax wrong?
A syntax error inside <IfModule mod_headers.c> in .htaccess can trigger a 500 error site-wide, since .htaccess is parsed on every request. Always keep a backup of the file before editing, and test in a private browser window immediately after saving.
What's the fastest way to get a passing grade without much testing?
Add X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and HSTS first — none of those will break anything on a normal site. Leave Content-Security-Policy for last and always start it in report-only mode; it's the one that needs real testing per site.