HTTP Security Headers for Shared Hosting and VPS: CSP, HSTS, X‑Frame‑Options and More

When we review sites on our shared hosting and VPS platforms during a security audit, we almost always see the same pattern: SSL is enabled, basic hardening is done, but HTTP security headers are missing or misconfigured. That means browsers are not using all the built‑in protections they already have for your visitors. In this guide, we will walk through the most important headers (HSTS, CSP, X‑Frame‑Options, Referrer‑Policy and more) and show you how to configure them safely on both shared hosting and VPS servers.

The focus here is practical: what each header really does, which values we recommend, and how to apply them via .htaccess (Apache, cPanel) or web server configs (Nginx/Apache on a VPS) without breaking your site. We will also touch on testing, common pitfalls we see on dchost.com, and simple starter profiles you can copy for WordPress, PHP apps and small business sites. If you want to go deeper into every single directive later, you can combine this article with our in‑depth HTTP security headers tutorial.

Why HTTP Security Headers Matter on Shared Hosting and VPS

HTTP security headers are additional instructions your server sends with every response. Browsers read them and enable extra protections around encryption, framing, content loading, cookies and more. They do not replace HTTPS, firewalls or secure coding, but they significantly reduce the impact of common web attacks and mistakes.

On shared hosting and VPS environments, headers are especially important because:

• You share infrastructure on many plans. Security headers add another isolation layer at the browser level, even if different sites run on the same server.
• Applications are frequently updated (WordPress plugins, themes, PHP frameworks). Headers help contain damage if a new vulnerability appears before you patch.
• Many attacks are purely browser‑side, such as clickjacking or data exfiltration via overly permissive cross‑origin rules. Headers let you tell browsers what is allowed.
• Compliance and trust requirements (PCI‑DSS, GDPR, KVKK) increasingly expect proper HTTPS and modern security headers as baseline hygiene.

If you have not yet migrated your site fully to HTTPS, start there first. Our full HTTP to HTTPS migration guide with HSTS and canonical settings explains that process step by step. Once HTTPS is stable, security headers are the natural next layer.

The Core HTTP Security Headers You Should Enable Everywhere

Let’s start with a practical shortlist. For most shared hosting and VPS setups, we recommend enabling at least the following headers:

• Strict-Transport-Security (HSTS)
• Content-Security-Policy (CSP) (even a simple one)
• X-Frame-Options (or frame-ancestors in CSP)
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy (formerly Feature-Policy)

We will go through each header, what it does and safe default values we use on dchost.com servers.

HSTS (Strict-Transport-Security)

What it does: Tells browsers to always use HTTPS for your domain (and optionally subdomains) for a defined period. This protects against protocol‑downgrade and cookie theft on insecure HTTP.

Typical value:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: How long (in seconds) the browser should remember to use HTTPS (1 year here).
• includeSubDomains: Apply to all subdomains (only if all of them support HTTPS correctly).
• preload: Signals your intent to join browser preload lists, where major browsers ship HSTS rules baked in.

Practical advice:

• Do not enable includeSubDomains or preload until you know all subdomains are permanently on HTTPS.
• If you are still stabilising HTTPS, start with a smaller value like max-age=86400 (1 day) and increase later.
• Remember: misconfigured HSTS can lock users out until the max-age expires.

We cover HSTS and its interaction with redirects and SEO in more detail in our full HTTPS migration and HSTS article.

X-Frame-Options (or frame-ancestors in CSP)

What it does: Controls whether your site can be embedded in an <iframe> on another site. This mitigates clickjacking attacks, where an attacker overlays invisible content over your page to capture clicks or keystrokes.

Common values:

• DENY – Site cannot be framed by any page (strongest).
• SAMEORIGIN – Only pages from the same origin can frame it.
• ALLOW-FROM https://example.com/ – Old, poorly supported syntax. Prefer CSP frame-ancestors instead.

Recommended:

• For most sites: X-Frame-Options: SAMEORIGIN.
• If you use a payment provider or widget that needs to frame your pages, move to CSP frame-ancestors and allow only the necessary origins.

Be cautious: we often see admins enable DENY and then discover that their admin dashboard, analytics, or third‑party integrations broke because they rely on iframes.

X-Content-Type-Options

What it does: Prevents browsers from “MIME sniffing” content types and treating files as something they are not, which can lead to unexpected script execution.

Recommended value:

X-Content-Type-Options: nosniff

This one is almost always safe to enable on any shared hosting or VPS site.

Referrer-Policy

What it does: Controls how much of the referring URL is sent when users click from your site to another. This protects query parameters, tokens and potentially sensitive path information.

Common values:

• no-referrer – Never send a referrer.
• no-referrer-when-downgrade – Default browser behaviour; not privacy‑friendly.
• strict-origin – Sends only the origin (no path/query) and only over HTTPS.
• strict-origin-when-cross-origin – Full URL to same‑origin, origin only to cross‑origin, and never when downgrading to HTTP.

Recommended value for most sites:

Referrer-Policy: strict-origin-when-cross-origin

It balances analytics needs with user privacy and is widely supported.

Permissions-Policy

What it does: Controls access to powerful browser features such as camera, microphone, geolocation, fullscreen and more, on a per‑origin basis.

Example:

Permissions-Policy: camera=(), microphone=(), geolocation=(self)

• () means no origin is allowed.
• (self) allows only the current origin.

Start by disabling features you are sure you do not use, and relax later if needed.

X-XSS-Protection (Legacy)

What it does: Enables or disables older browser XSS filters. Modern browsers either ignore this header or provide better protection through CSP.

Recommendation: You can omit this header on new deployments. If you want to be explicit, use:

X-XSS-Protection: 0

Focus your effort on a well‑configured CSP instead.

CSP Basics: Getting Started Without Breaking Your Site

Content-Security-Policy (CSP) is the most powerful and most frequently misconfigured header we see. It defines which sources are allowed to load scripts, styles, images, fonts, frames and more. A good CSP can drastically reduce XSS and data exfiltration risks. A bad CSP can break your entire front‑end.

A Minimal, Safer-Than-Nothing CSP

If you are on shared hosting with a simple site (few external scripts, maybe a CDN), start with a conservative but not overly strict policy like this:

Content-Security-Policy: 
  default-src 'self'; 
  img-src 'self' data: https:; 
  script-src 'self' https://www.googletagmanager.com; 
  style-src 'self' 'unsafe-inline'; 
  font-src 'self' data: https:; 
  connect-src 'self'; 
  frame-ancestors 'self';

Breakdown:

• default-src 'self': Block everything by default except same‑origin resources.
• img-src: Allow images from your site, data: URIs and HTTPS (for CDNs or third‑party images).
• script-src: Allow scripts from your own domain and a specific analytics manager. Replace with the tools you actually use.
• style-src 'unsafe-inline': Allows inline styles, which many CMSs still rely on. Remove 'unsafe-inline' when you are ready to refactor.
• frame-ancestors 'self': Only your own origin can frame your site, which replaces X‑Frame‑Options for modern browsers.

Start with Report‑Only mode in production so you can see what would break before enforcing the policy:

Content-Security-Policy-Report-Only: default-src 'self'; ...

For a deeper dive into nonces, hashes and fine‑grained CSP on WordPress and Laravel, see our article on using CSP nonces and hashes without breaking inline scripts.

CSP on WordPress and PHP Apps

On CMS platforms like WordPress, a strict CSP can be challenging because many themes and plugins rely on inline JavaScript and styles. Some practical tips from what we see in real projects:

• Use a CSP plugin if you are not comfortable editing headers manually, but still test carefully on staging.
• Avoid 'unsafe-inline' and 'unsafe-eval' long‑term. They weaken CSP significantly. Gradually refactor custom code to external files or use nonces/hashes.
• Whitelist only what you really use: analytics, tag managers, payment gateways. Avoid wide patterns like *.example.com unless truly needed.
• Combine CSP with cookie hardening. Our article on SameSite=Lax/Strict, Secure and HttpOnly cookies shows how CSP and cookie flags reinforce each other.

Configuring Security Headers on Shared Hosting (.htaccess & Panel)

On most shared hosting platforms (including our cPanel and similar stacks), you configure HTTP headers using .htaccess rules for Apache. These rules live in your site’s document root (often public_html).

1. Basic Apache .htaccess Examples

Add the following inside your .htaccess file. Ensure mod_headers is enabled (it is on our shared hosting by default):

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
  # Minimal CSP example – adjust to your site
  Header set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';"
</IfModule>

Notes:

• Use double quotes around header values and escape any inner quotes with ' if needed.
• Place rules near the top of the file, before complex rewrite rules, to make them easier to maintain.
• If your panel or a plugin already sets headers, avoid duplicating them. Duplicate headers can confuse browsers.

2. Testing on Shared Hosting

After editing .htaccess, test your site:

• Open your site in Chrome/Firefox, press F12, and check the Network tab. Click the main request and inspect the Response Headers.
• Use a tool like curl -I https://example.com from a terminal to see headers quickly.
• Optionally, use online scanners (like security header checkers) to get a grade and suggestions.

If you see 500 errors after editing .htaccess, there is usually a syntax issue. Comment out the last changes and re‑add them step by step.

3. Panel-Level Header Settings

Some control panels allow adding custom headers via a GUI (for example through “Additional Apache directives” or “HTTP headers” sections). Under the hood, these usually inject the same Header set directives into the vhost configuration. The rules are the same:

• Avoid duplicate headers or conflicting values.
• Test changes first on a staging or test subdomain. Our guide on setting up a WordPress staging environment on shared hosting is very handy here.

Configuring Security Headers on a VPS (Nginx & Apache)

On a VPS, you have full control of your web server configuration. That is powerful but also means mistakes can affect many sites at once. We highly recommend making changes in small steps and reloading the web server cautiously.

1. Nginx Examples

Add these directives inside your server { ... } block, preferably in a common include file you reuse across sites:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(self)" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';" always;

Key points:

• Use always so headers are added even on 4xx/5xx error responses.
• If you serve static files from a different server block or location, ensure headers apply there too (e.g. in location / or via an include security-headers.conf; file).
• After changes, run nginx -t to test configuration, then systemctl reload nginx.

2. Apache on a VPS

On a VPS, you can define headers in vhost config files instead of .htaccess. That is more efficient and easier to manage in version control.

<VirtualHost *:443>
  ServerName example.com
  ...
  <IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
    Header set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';"
  </IfModule>
</VirtualHost>

Then reload Apache: systemctl reload httpd or systemctl reload apache2 depending on your distro.

If you are new to VPS hardening, our VPS security hardening checklist pairs nicely with security header work.

3. Reverse Proxy and CDN Layers

If you use a reverse proxy (like Nginx in front of Apache) or a CDN/WAF in front of your origin, decide where to set the headers:

• Origin‑side headers: More portable if you change CDN later; your config lives with the app.
• CDN‑side headers: Can be easier to tweak and test, but be careful not to shadow or override origin headers unexpectedly.

Our Cloudflare security settings guide shows how to combine WAF rules with origin‑side security headers for a layered defence.

Testing, Monitoring and Rolling Out Safely

Security headers are easy to misconfigure, especially CSP and HSTS. A disciplined rollout avoids production surprises.

Step 1: Start in Report-Only Mode (for CSP)

On your staging site or a low‑risk domain, start CSP in Content-Security-Policy-Report-Only mode. You can configure report-uri or report-to directives to send violation reports to a service or your own endpoint. Once the reports look clean (no unexpected blocked resources), switch to enforcing Content-Security-Policy.

Step 2: Enable HSTS Gradually

Begin with a small max-age (e.g. one day), ensure all HTTP → HTTPS redirects behave correctly and that no mixed content warnings appear. Then increase to 30 days, 6 months, and only later consider preload.

If you are unsure whether your site is fully HTTPS‑clean, our article on fixing mixed content and insecure HTTP requests after enabling SSL is a useful checklist.

Step 3: Automate Checks

For important sites (e‑commerce, SaaS, client portals), add header checks into your monitoring:

• Use a simple script with curl -I to verify key headers and run it via cron.
• Integrate basic header validation into your CI/CD pipeline so new deployments do not accidentally remove or weaken policies.
• Combine with uptime and SSL expiry monitoring. Our guide to website uptime monitoring and alerting can be extended with header checks as well.

Common Pitfalls We See on dchost.com Servers

After auditing many real‑world sites, a few patterns keep appearing. Being aware of them will save you time.

1. Aggressive HSTS on Half‑Migrated Domains

A site enables HSTS with includeSubDomains; preload while some subdomains still serve HTTP only (old blog, forgotten admin tool, mail UI). Users then get locked out with scary browser errors. Fixing this can take weeks while you clean up all subdomains and wait for preload lists to update. Always verify subdomains first.

2. Overly Strict CSP That Breaks Admin Panels

Another frequent case: a very strict script-src 'self' policy without nonces/hashes on a WordPress or Laravel admin area that uses inline scripts or third‑party resources. Admin pages partially load, but buttons stop working or AJAX calls silently fail. Start with report‑only mode and gradually tighten.

3. X-Frame-Options Blocking Legitimate Integrations

We regularly see X-Frame-Options: DENY deployed on sites that need to be embedded by payment providers, booking widgets or partner dashboards. The result: invisible broken flows that users simply abandon. If framing is part of your business flow, switch to CSP frame-ancestors and allow only the exact domains you trust.

4. Conflicting Headers from Multiple Layers

Headers set in three places (application, server config, CDN) often conflict. For example, the app sets a lenient Referrer-Policy, the CDN sets a strict one, and debugging becomes confusing. Decide where each header should live and keep your configuration DRY.

Example Header Sets for Common Hosting Scenarios

To make this more concrete, here are three starter profiles you can adapt. Do not copy blindly; treat them as a baseline and adjust to your stack.

1. Small Brochure Site on Shared Hosting

Goal: solid protection with minimal risk of breaking things.

Strict-Transport-Security: max-age=31536000;
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
Content-Security-Policy: 
  default-src 'self'; 
  img-src 'self' data: https:; 
  script-src 'self'; 
  style-src 'self' 'unsafe-inline'; 
  font-src 'self' data: https:; 
  frame-ancestors 'self';

Apply this via .htaccess and test forms and contact widgets thoroughly.

2. WordPress Blog on Shared Hosting or VPS

Goal: balance flexibility (plugins, themes) with improved security.

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
Content-Security-Policy: 
  default-src 'self'; 
  img-src 'self' data: https:; 
  script-src 'self' https://www.googletagmanager.com; 
  style-src 'self' 'unsafe-inline'; 
  font-src 'self' data: https:; 
  connect-src 'self'; 
  frame-ancestors 'self';

Then, iteratively tighten script-src and remove 'unsafe-inline' as you refactor custom code. Combine this with the hardening steps in our WordPress security guide on shared hosting.

3. E‑Commerce or Login-Heavy App on a VPS

Goal: stronger guarantees and a path towards compliance (PCI‑DSS, etc.).

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=(self)
Content-Security-Policy: 
  default-src 'self'; 
  img-src 'self' data: https:; 
  script-src 'self' 'nonce-...'; 
  style-src 'self'; 
  font-src 'self' data: https:; 
  connect-src 'self' https://api.payment-gateway.com; 
  frame-ancestors 'self' https://trusted-partner.com;

This kind of configuration usually goes together with stricter cookie flags, WAF rules and secure deployment pipelines. Our article on PCI‑DSS compliant e‑commerce hosting dives into that wider context.

Conclusion: Turn Security Headers into a Normal Part of Your Stack

HTTP security headers are not just for huge platforms; they are a low‑cost, high‑impact layer that every shared hosting and VPS site can (and should) use. HSTS makes HTTPS the default, CSP gives you fine‑grained control over what the browser loads, X‑Frame‑Options and frame-ancestors stop clickjacking, and supporting headers like Referrer‑Policy, Permissions‑Policy and X‑Content-Type‑Options close off many subtle attack paths.

Our recommendation is simple: start small, roll out gradually, and treat headers as code. Version them, review them when your application changes, and test them just like any other part of your infrastructure. If you host with us at dchost.com and are unsure how to apply these examples to your shared account, VPS or dedicated setup, our team is happy to look at your current configuration and suggest a safe plan. From there, you can build on this foundation with deeper hardening using guides like our friendly HTTP security headers checklist and broader articles on TLS, WAF and VPS security. The goal is not perfection on day one, but a steady, controlled improvement of your site’s real‑world protection.