How to Enable Security Headers (CSP, HSTS, X-Frame-Options) in StackCP

Security headers work silently in the background, invisible to your visitors, but genuinely effective at blocking common web attacks. StackCP includes a dedicated Security Headers tool that lets you configure these headers directly, without editing server configuration files yourself — including the ability to save your preferred settings as a reusable profile.

This guide explains what each available header does and exactly how to configure them in StackCP.

What Are Security Headers, and Why Do They Matter?

When a browser requests your website, your server sends back the page content along with a set of "headers" — instructions telling the browser how to handle that content safely. Security headers specifically reduce the risk of attacks like cross-site scripting (XSS), clickjacking, and protocol downgrade attacks that could otherwise expose visitors on unsecured networks.

Step 1: Locate Security Headers in StackCP

1. Log in to StackCP.
2. Go to Manage Hosting, then select Options > Manage on the site you want to configure.
3. Select the Security Headers icon within the CDN section.

Step 2: Understanding Security Header Profiles

Before configuring individual headers, it's worth knowing about Security Header Profiles — a feature that lets you save a complete header configuration under a named profile, then load that same profile onto other packages you manage. This is especially useful if you manage multiple sites and want consistent security settings across all of them without reconfiguring each one from scratch.

To create a profile: configure your headers as described below, then save the configuration with a meaningful name. To load a profile: select it from your saved list, and its settings are applied instantly to the current package.

Step 3: X-Frame-Options — Prevent Clickjacking

This header controls whether your pages can be displayed inside a frame on another site, which is the mechanism behind clickjacking attacks (where a visitor is tricked into clicking something disguised inside an invisible frame). Two options are available:

• DENY — the page cannot be displayed in a frame at all, regardless of the site attempting it.
• SAMEORIGIN — the page can only be framed by pages on your own site.

For most websites, SAMEORIGIN is a sensible default, allowing your own site to frame its own content where needed while blocking outside sites entirely. Note that this protection only applies for visitors using a browser that supports the header, which covers the overwhelming majority of modern browsers.

Step 4: X-Content-Type-Options — Prevent MIME-Type Sniffing

This header has a single available setting, nosniff, which tells the browser not to try to "guess" a file's type differently from what the server declares. Specifically, it blocks a request if the destination is a stylesheet but the declared type isn't text/css, or a script but the declared type isn't a JavaScript MIME type. This is a low-risk, safe-to-enable header for virtually any website.

Step 5: Referrer-Policy — Control What Referrer Information Is Shared

This header controls how much information about the page a visitor came from is passed along when they click a link to another site. StackCP offers several options, including:

• no-referrer — no referrer information is sent at all.
• strict-origin-when-cross-origin — this is the general default: sends full details for same-origin requests, but only the origin (not the full path) for cross-origin requests, and nothing at all when going from a secure (HTTPS) site to a less secure (HTTP) one.
• same-origin — full referrer details for same-origin requests only; nothing for cross-origin requests.
• unsafe-url — sends full referrer details on every request, regardless of security level. This option can leak potentially private information from HTTPS URLs to insecure destinations, so it should be used with real caution, if at all.

For most websites, the default strict-origin-when-cross-origin setting offers a sensible, privacy-conscious balance without needing adjustment.

Step 6: Strict-Transport-Security (HSTS) — Enforce HTTPS

HSTS tells browsers to always connect to your site using HTTPS, never falling back to unencrypted HTTP. The available settings are:

• max-age — the time, in seconds, that the browser should remember to enforce HTTPS-only access.
• includeSubDomains — an optional setting that extends the rule to all of your site's subdomains as well.

Important: only enable HSTS after confirming HTTPS works correctly across your entire site (see our SSL/TLS certificate guide). Start with a shorter max-age value while you confirm everything works as expected, and consider increasing it over time once you're confident.

Step 7: X-XSS-Protection — Legacy Browser XSS Filtering

This header is specifically a feature of older versions of Internet Explorer, Chrome, and Safari, designed to stop pages from loading when a reflected cross-site scripting attack is detected. The available options are:

• 0 — disables XSS filtering.
• 1 — enables filtering; the browser sanitizes the page if an attack is detected.
• 1; mode=block — enables filtering; the browser blocks the page entirely rather than sanitizing it.
• 1; report= (Chromium only) — enables filtering and sends a violation report, using the same reporting mechanism as CSP's report-uri directive.

It's worth knowing that this protection is largely unnecessary in modern browsers for sites that already implement a strong Content-Security-Policy disabling inline JavaScript — but it can still add a layer of protection for visitors on older browsers that don't yet support CSP.

Step 8: Content-Security-Policy (CSP) — The Most Powerful, Most Careful Header

CSP lets you control exactly which sources are allowed to load scripts, styles, images, and other resources on your page, which is a strong defence against cross-site scripting attacks. This is also the header most likely to cause something on your site to stop working if configured too strictly, since it will block any resource — including ones you may not realize your site depends on, like a chat widget, payment gateway script, or analytics tool — that isn't on your approved list.

Configure CSP carefully:

1. Review every third-party resource your site actually loads (analytics, chat widgets, payment gateways, embedded fonts or videos) before restricting things broadly.
2. Build your policy to explicitly allow those known, trusted sources.
3. After saving, click through your site's key pages and interactive features (forms, chat, checkout) to confirm nothing has broken.

If you're not confident identifying every third-party resource your site depends on, a more cautious approach is to start with the other headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, HSTS), which carry much lower risk of unintended breakage, and treat CSP as a later, more careful step — ideally with a developer's input if your site has several third-party integrations.

Common Mistakes Beginners Make

• Enabling HSTS before confirming HTTPS works everywhere. Test thoroughly first.
• Configuring a strict CSP without first auditing your third-party resources. This is the most common way a chat widget or payment script ends up broken.
• Not using Security Header Profiles if you manage multiple sites, resulting in inconsistent, manually reconfigured settings across your portfolio.
• Setting unsafe-url for Referrer-Policy without understanding it can leak information from secure pages to insecure destinations.

Troubleshooting

"My chat widget or payment gateway stopped working after enabling CSP." Review your CSP configuration and explicitly add the specific domain the broken resource loads from, then retest.

"My site shows a browser warning about HTTPS after enabling HSTS." This typically means part of your site isn't fully served over HTTPS. Fix the underlying certificate or redirect issue, and the warning should resolve on subsequent visits once the browser re-checks.

"I manage several sites and don't want to configure headers individually for each." Use Security Header Profiles — configure your preferred settings once, save as a profile, and load it onto your other packages.

A Sensible Rollout Order for Beginners

Rather than enabling every header at once, a staged approach reduces risk and makes it easier to pinpoint the cause if something does go wrong:

1. Start with X-Frame-Options (SAMEORIGIN) and X-Content-Type-Options (nosniff). Both are low-risk with essentially no chance of breaking legitimate functionality.
2. Set Referrer-Policy, keeping the default strict-origin-when-cross-origin unless you have a specific reason to change it.
3. Confirm HTTPS works flawlessly across your entire site, then enable HSTS with a modest max-age to start.
4. Save this configuration as a Security Header Profile once you're happy with it, so it's easy to reapply to other sites you manage.
5. Only then, carefully, move on to CSP — after auditing every third-party script, widget, and embed your site actually uses.

This order front-loads the safest, highest-value changes and treats the most complex, highest-risk header (CSP) as a deliberate final step rather than something to enable alongside everything else on day one.

Why These Headers Matter Together, Not Just Individually

It's worth understanding that these headers address different, specific attack types rather than one general "security" concept:

• X-Frame-Options stops your content from being embedded and manipulated inside another site's page (clickjacking).
• X-Content-Type-Options stops a browser from being tricked into executing a file as something other than what it actually is.
• Referrer-Policy limits how much information about your visitors' browsing leaks to other sites they click through to.
• HSTS closes the window where an attacker on the same network could intercept an unencrypted connection before it upgrades to HTTPS.
• CSP is the broadest of the group, restricting exactly which sources are allowed to execute code or load resources on your pages at all.

None of these individually makes a site "unhackable" — but layered together, alongside StackCP's other security tools like Malware Scan and Block Visitors, they meaningfully raise the difficulty of a successful attack.

Managing Headers Across a Reseller Hosting Business

If you're setting up hosting for multiple customers, Security Header Profiles are particularly valuable — you can build one well-tested baseline profile (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and a conservative HSTS setting) and apply it consistently across new customer sites as you onboard them, rather than configuring headers manually for every single package. CSP, given its higher risk of breaking site-specific functionality, is usually better handled on a per-site basis after reviewing what that particular site actually depends on.