{"id":4773,"date":"2026-02-08T16:13:12","date_gmt":"2026-02-08T13:13:12","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/http-security-headers-for-shared-hosting-and-vps-csp-hsts-x-frame-options-and-more\/"},"modified":"2026-02-08T16:13:12","modified_gmt":"2026-02-08T13:13:12","slug":"http-security-headers-for-shared-hosting-and-vps-csp-hsts-x-frame-options-and-more","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/http-security-headers-for-shared-hosting-and-vps-csp-hsts-x-frame-options-and-more\/","title":{"rendered":"HTTP Security Headers for Shared Hosting and VPS: CSP, HSTS, X\u2011Frame\u2011Options and More"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When we review sites on our shared hosting and <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> 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\u2011in protections they already have for your visitors. In this guide, we will walk through the most important headers (HSTS, CSP, X\u2011Frame\u2011Options, Referrer\u2011Policy and more) and show you how to configure them safely on both shared hosting and VPS servers.<\/p>\n<p>The focus here is practical: what each header really does, which values we recommend, and how to apply them via <code>.htaccess<\/code> (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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/\">in\u2011depth HTTP security headers tutorial<\/a>.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_HTTP_Security_Headers_Matter_on_Shared_Hosting_and_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> Why HTTP Security Headers Matter on Shared Hosting and VPS<\/a><\/li><li><a href=\"#The_Core_HTTP_Security_Headers_You_Should_Enable_Everywhere\"><span class=\"toc_number toc_depth_1\">2<\/span> The Core HTTP Security Headers You Should Enable Everywhere<\/a><ul><li><a href=\"#HSTS_Strict-Transport-Security\"><span class=\"toc_number toc_depth_2\">2.1<\/span> HSTS (Strict-Transport-Security)<\/a><\/li><li><a href=\"#X-Frame-Options_or_frame-ancestors_in_CSP\"><span class=\"toc_number toc_depth_2\">2.2<\/span> X-Frame-Options (or frame-ancestors in CSP)<\/a><\/li><li><a href=\"#X-Content-Type-Options\"><span class=\"toc_number toc_depth_2\">2.3<\/span> X-Content-Type-Options<\/a><\/li><li><a href=\"#Referrer-Policy\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Referrer-Policy<\/a><\/li><li><a href=\"#Permissions-Policy\"><span class=\"toc_number toc_depth_2\">2.5<\/span> Permissions-Policy<\/a><\/li><li><a href=\"#X-XSS-Protection_Legacy\"><span class=\"toc_number toc_depth_2\">2.6<\/span> X-XSS-Protection (Legacy)<\/a><\/li><\/ul><\/li><li><a href=\"#CSP_Basics_Getting_Started_Without_Breaking_Your_Site\"><span class=\"toc_number toc_depth_1\">3<\/span> CSP Basics: Getting Started Without Breaking Your Site<\/a><ul><li><a href=\"#A_Minimal_Safer-Than-Nothing_CSP\"><span class=\"toc_number toc_depth_2\">3.1<\/span> A Minimal, Safer-Than-Nothing CSP<\/a><\/li><li><a href=\"#CSP_on_WordPress_and_PHP_Apps\"><span class=\"toc_number toc_depth_2\">3.2<\/span> CSP on WordPress and PHP Apps<\/a><\/li><\/ul><\/li><li><a href=\"#Configuring_Security_Headers_on_Shared_Hosting_htaccess_Panel\"><span class=\"toc_number toc_depth_1\">4<\/span> Configuring Security Headers on Shared Hosting (.htaccess &amp; Panel)<\/a><ul><li><a href=\"#1_Basic_Apache_htaccess_Examples\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1. Basic Apache .htaccess Examples<\/a><\/li><li><a href=\"#2_Testing_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2. Testing on Shared Hosting<\/a><\/li><li><a href=\"#3_Panel-Level_Header_Settings\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3. Panel-Level Header Settings<\/a><\/li><\/ul><\/li><li><a href=\"#Configuring_Security_Headers_on_a_VPS_Nginx_Apache\"><span class=\"toc_number toc_depth_1\">5<\/span> Configuring Security Headers on a VPS (Nginx &amp; Apache)<\/a><ul><li><a href=\"#1_Nginx_Examples\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Nginx Examples<\/a><\/li><li><a href=\"#2_Apache_on_a_VPS\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Apache on a VPS<\/a><\/li><li><a href=\"#3_Reverse_Proxy_and_CDN_Layers\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Reverse Proxy and CDN Layers<\/a><\/li><\/ul><\/li><li><a href=\"#Testing_Monitoring_and_Rolling_Out_Safely\"><span class=\"toc_number toc_depth_1\">6<\/span> Testing, Monitoring and Rolling Out Safely<\/a><ul><li><a href=\"#Step_1_Start_in_Report-Only_Mode_for_CSP\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Step 1: Start in Report-Only Mode (for CSP)<\/a><\/li><li><a href=\"#Step_2_Enable_HSTS_Gradually\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Step 2: Enable HSTS Gradually<\/a><\/li><li><a href=\"#Step_3_Automate_Checks\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Step 3: Automate Checks<\/a><\/li><\/ul><\/li><li><a href=\"#Common_Pitfalls_We_See_on_dchostcom_Servers\"><span class=\"toc_number toc_depth_1\">7<\/span> Common Pitfalls We See on dchost.com Servers<\/a><ul><li><a href=\"#1_Aggressive_HSTS_on_HalfMigrated_Domains\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Aggressive HSTS on Half\u2011Migrated Domains<\/a><\/li><li><a href=\"#2_Overly_Strict_CSP_That_Breaks_Admin_Panels\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Overly Strict CSP That Breaks Admin Panels<\/a><\/li><li><a href=\"#3_X-Frame-Options_Blocking_Legitimate_Integrations\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. X-Frame-Options Blocking Legitimate Integrations<\/a><\/li><li><a href=\"#4_Conflicting_Headers_from_Multiple_Layers\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Conflicting Headers from Multiple Layers<\/a><\/li><\/ul><\/li><li><a href=\"#Example_Header_Sets_for_Common_Hosting_Scenarios\"><span class=\"toc_number toc_depth_1\">8<\/span> Example Header Sets for Common Hosting Scenarios<\/a><ul><li><a href=\"#1_Small_Brochure_Site_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 1. Small Brochure Site on Shared Hosting<\/a><\/li><li><a href=\"#2_WordPress_Blog_on_Shared_Hosting_or_VPS\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 2. WordPress Blog on Shared Hosting or VPS<\/a><\/li><li><a href=\"#3_ECommerce_or_Login-Heavy_App_on_a_VPS\"><span class=\"toc_number toc_depth_2\">8.3<\/span> 3. E\u2011Commerce or Login-Heavy App on a VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_Turn_Security_Headers_into_a_Normal_Part_of_Your_Stack\"><span class=\"toc_number toc_depth_1\">9<\/span> Conclusion: Turn Security Headers into a Normal Part of Your Stack<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_HTTP_Security_Headers_Matter_on_Shared_Hosting_and_VPS\">Why HTTP Security Headers Matter on Shared Hosting and VPS<\/span><\/h2>\n<p>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.<\/p>\n<p>On shared hosting and VPS environments, headers are especially important because:<\/p>\n<ul>\n<li><strong>You share infrastructure<\/strong> on many plans. Security headers add another isolation layer at the browser level, even if different sites run on the same server.<\/li>\n<li><strong>Applications are frequently updated<\/strong> (WordPress plugins, themes, PHP frameworks). Headers help contain damage if a new vulnerability appears before you patch.<\/li>\n<li><strong>Many attacks are purely browser\u2011side<\/strong>, such as clickjacking or data exfiltration via overly permissive cross\u2011origin rules. Headers let you tell browsers what is allowed.<\/li>\n<li><strong>Compliance and trust<\/strong> requirements (PCI\u2011DSS, GDPR, KVKK) increasingly expect proper HTTPS and modern security headers as baseline hygiene.<\/li>\n<\/ul>\n<p>If you have not yet migrated your site fully to HTTPS, start there first. Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpsye-gecis-rehberi-seo-kayipsiz-ssl-migrasyonu-hsts-ve-canonical-ayarlari\/\">full HTTP to HTTPS migration guide with HSTS and canonical settings<\/a> explains that process step by step. Once HTTPS is stable, security headers are the natural next layer.<\/p>\n<h2><span id=\"The_Core_HTTP_Security_Headers_You_Should_Enable_Everywhere\">The Core HTTP Security Headers You Should Enable Everywhere<\/span><\/h2>\n<p>Let\u2019s start with a practical shortlist. For most shared hosting and VPS setups, we recommend enabling at least the following headers:<\/p>\n<ul>\n<li><strong>Strict-Transport-Security (HSTS)<\/strong><\/li>\n<li><strong>Content-Security-Policy (CSP)<\/strong> (even a simple one)<\/li>\n<li><strong>X-Frame-Options<\/strong> (or <code>frame-ancestors<\/code> in CSP)<\/li>\n<li><strong>X-Content-Type-Options<\/strong><\/li>\n<li><strong>Referrer-Policy<\/strong><\/li>\n<li><strong>Permissions-Policy<\/strong> (formerly Feature-Policy)<\/li>\n<\/ul>\n<p>We will go through each header, what it does and safe default values we use on dchost.com servers.<\/p>\n<h3><span id=\"HSTS_Strict-Transport-Security\">HSTS (Strict-Transport-Security)<\/span><\/h3>\n<p><strong>What it does:<\/strong> Tells browsers to always use HTTPS for your domain (and optionally subdomains) for a defined period. This protects against protocol\u2011downgrade and cookie theft on insecure HTTP.<\/p>\n<p><strong>Typical value:<\/strong><\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Strict-Transport-Security: max-age=31536000; includeSubDomains; preload\n<\/code><\/pre>\n<ul>\n<li><code>max-age<\/code>: How long (in seconds) the browser should remember to use HTTPS (1 year here).<\/li>\n<li><code>includeSubDomains<\/code>: Apply to all subdomains (only if <em>all<\/em> of them support HTTPS correctly).<\/li>\n<li><code>preload<\/code>: Signals your intent to join browser preload lists, where major browsers ship HSTS rules baked in.<\/li>\n<\/ul>\n<p><strong>Practical advice:<\/strong><\/p>\n<ul>\n<li>Do <em>not<\/em> enable <code>includeSubDomains<\/code> or <code>preload<\/code> until you know all subdomains are permanently on HTTPS.<\/li>\n<li>If you are still stabilising HTTPS, start with a smaller value like <code>max-age=86400<\/code> (1 day) and increase later.<\/li>\n<li>Remember: misconfigured HSTS can lock users out until the <code>max-age<\/code> expires.<\/li>\n<\/ul>\n<p>We cover HSTS and its interaction with redirects and SEO in more detail in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/full-http-to-https-migration-guide-301-yonlendirme-hsts-ve-seoyu-korumak\/\">full HTTPS migration and HSTS article<\/a>.<\/p>\n<h3><span id=\"X-Frame-Options_or_frame-ancestors_in_CSP\">X-Frame-Options (or frame-ancestors in CSP)<\/span><\/h3>\n<p><strong>What it does:<\/strong> Controls whether your site can be embedded in an <code>&lt;iframe&gt;<\/code> on another site. This mitigates clickjacking attacks, where an attacker overlays invisible content over your page to capture clicks or keystrokes.<\/p>\n<p><strong>Common values:<\/strong><\/p>\n<ul>\n<li><code>DENY<\/code> \u2013 Site cannot be framed by any page (strongest).<\/li>\n<li><code>SAMEORIGIN<\/code> \u2013 Only pages from the same origin can frame it.<\/li>\n<li><code>ALLOW-FROM https:\/\/example.com\/<\/code> \u2013 Old, poorly supported syntax. Prefer CSP <code>frame-ancestors<\/code> instead.<\/li>\n<\/ul>\n<p><strong>Recommended:<\/strong><\/p>\n<ul>\n<li>For most sites: <code>X-Frame-Options: SAMEORIGIN<\/code>.<\/li>\n<li>If you use a payment provider or widget that needs to frame your pages, move to CSP <code>frame-ancestors<\/code> and allow only the necessary origins.<\/li>\n<\/ul>\n<p>Be cautious: we often see admins enable <code>DENY<\/code> and then discover that their admin dashboard, analytics, or third\u2011party integrations broke because they rely on iframes.<\/p>\n<h3><span id=\"X-Content-Type-Options\">X-Content-Type-Options<\/span><\/h3>\n<p><strong>What it does:<\/strong> Prevents browsers from \u201cMIME sniffing\u201d content types and treating files as something they are not, which can lead to unexpected script execution.<\/p>\n<p><strong>Recommended value:<\/strong><\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">X-Content-Type-Options: nosniff\n<\/code><\/pre>\n<p>This one is almost always safe to enable on any shared hosting or VPS site.<\/p>\n<h3><span id=\"Referrer-Policy\">Referrer-Policy<\/span><\/h3>\n<p><strong>What it does:<\/strong> 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.<\/p>\n<p><strong>Common values:<\/strong><\/p>\n<ul>\n<li><code>no-referrer<\/code> \u2013 Never send a referrer.<\/li>\n<li><code>no-referrer-when-downgrade<\/code> \u2013 Default browser behaviour; not privacy\u2011friendly.<\/li>\n<li><code>strict-origin<\/code> \u2013 Sends only the origin (no path\/query) and only over HTTPS.<\/li>\n<li><code>strict-origin-when-cross-origin<\/code> \u2013 Full URL to same\u2011origin, origin only to cross\u2011origin, and never when downgrading to HTTP.<\/li>\n<\/ul>\n<p><strong>Recommended value for most sites:<\/strong><\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Referrer-Policy: strict-origin-when-cross-origin\n<\/code><\/pre>\n<p>It balances analytics needs with user privacy and is widely supported.<\/p>\n<h3><span id=\"Permissions-Policy\">Permissions-Policy<\/span><\/h3>\n<p><strong>What it does:<\/strong> Controls access to powerful browser features such as camera, microphone, geolocation, fullscreen and more, on a per\u2011origin basis.<\/p>\n<p><strong>Example:<\/strong><\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">Permissions-Policy: camera=(), microphone=(), geolocation=(self)\n<\/code><\/pre>\n<ul>\n<li><code>()<\/code> means no origin is allowed.<\/li>\n<li><code>(self)<\/code> allows only the current origin.<\/li>\n<\/ul>\n<p>Start by disabling features you are sure you do not use, and relax later if needed.<\/p>\n<h3><span id=\"X-XSS-Protection_Legacy\">X-XSS-Protection (Legacy)<\/span><\/h3>\n<p><strong>What it does:<\/strong> Enables or disables older browser XSS filters. Modern browsers either ignore this header or provide better protection through CSP.<\/p>\n<p><strong>Recommendation:<\/strong> You can omit this header on new deployments. If you want to be explicit, use:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">X-XSS-Protection: 0\n<\/code><\/pre>\n<p>Focus your effort on a well\u2011configured CSP instead.<\/p>\n<h2><span id=\"CSP_Basics_Getting_Started_Without_Breaking_Your_Site\">CSP Basics: Getting Started Without Breaking Your Site<\/span><\/h2>\n<p>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\u2011end.<\/p>\n<h3><span id=\"A_Minimal_Safer-Than-Nothing_CSP\">A Minimal, Safer-Than-Nothing CSP<\/span><\/h3>\n<p>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:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Content-Security-Policy: \n  default-src 'self'; \n  img-src 'self' data: https:; \n  script-src 'self' https:\/\/www.googletagmanager.com; \n  style-src 'self' 'unsafe-inline'; \n  font-src 'self' data: https:; \n  connect-src 'self'; \n  frame-ancestors 'self';\n<\/code><\/pre>\n<p>Breakdown:<\/p>\n<ul>\n<li><code>default-src 'self'<\/code>: Block everything by default except same\u2011origin resources.<\/li>\n<li><code>img-src<\/code>: Allow images from your site, <code>data:<\/code> URIs and HTTPS (for CDNs or third\u2011party images).<\/li>\n<li><code>script-src<\/code>: Allow scripts from your own domain and a specific analytics manager. Replace with the tools you actually use.<\/li>\n<li><code>style-src 'unsafe-inline'<\/code>: Allows inline styles, which many CMSs still rely on. Remove <code>'unsafe-inline'<\/code> when you are ready to refactor.<\/li>\n<li><code>frame-ancestors 'self'<\/code>: Only your own origin can frame your site, which replaces X\u2011Frame\u2011Options for modern browsers.<\/li>\n<\/ul>\n<p>Start with <strong>Report\u2011Only mode<\/strong> in production so you can see what would break before enforcing the policy:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">Content-Security-Policy-Report-Only: default-src 'self'; ...\n<\/code><\/pre>\n<p>For a deeper dive into nonces, hashes and fine\u2011grained CSP on WordPress and Laravel, see our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/cspyi-dogru-kurmak-wordpress-laravelde-nonce-hash-report-to-ve-inline-scriptleri-tatli-tatli-ehlilestirmek\/\">on using CSP nonces and hashes without breaking inline scripts<\/a>.<\/p>\n<h3><span id=\"CSP_on_WordPress_and_PHP_Apps\">CSP on WordPress and PHP Apps<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li><strong>Use a CSP plugin<\/strong> if you are not comfortable editing headers manually, but still test carefully on staging.<\/li>\n<li><strong>Avoid <code>'unsafe-inline'<\/code> and <code>'unsafe-eval'<\/code> long\u2011term<\/strong>. They weaken CSP significantly. Gradually refactor custom code to external files or use nonces\/hashes.<\/li>\n<li><strong>Whitelist only what you really use<\/strong>: analytics, tag managers, payment gateways. Avoid wide patterns like <code>*.example.com<\/code> unless truly needed.<\/li>\n<li><strong>Combine CSP with cookie hardening<\/strong>. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/samesitelax-mi-strict-mi-secure-ve-httponly-ile-nginx-apachede-cerezleri-tertemiz-nasil-kurarsin\/\">SameSite=Lax\/Strict, Secure and HttpOnly cookies<\/a> shows how CSP and cookie flags reinforce each other.<\/li>\n<\/ul>\n<h2><span id=\"Configuring_Security_Headers_on_Shared_Hosting_htaccess_Panel\">Configuring Security Headers on Shared Hosting (.htaccess &amp; Panel)<\/span><\/h2>\n<p>On most shared hosting platforms (including our cPanel and similar stacks), you configure HTTP headers using <code>.htaccess<\/code> rules for Apache. These rules live in your site\u2019s document root (often <code>public_html<\/code>).<\/p>\n<h3><span id=\"1_Basic_Apache_htaccess_Examples\">1. Basic Apache .htaccess Examples<\/span><\/h3>\n<p>Add the following inside your <code>.htaccess<\/code> file. Ensure <code>mod_headers<\/code> is enabled (it is on our shared hosting by default):<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">&lt;IfModule mod_headers.c&gt;\n  Header always set Strict-Transport-Security &quot;max-age=31536000; includeSubDomains; preload&quot;\n  Header always set X-Frame-Options &quot;SAMEORIGIN&quot;\n  Header always set X-Content-Type-Options &quot;nosniff&quot;\n  Header always set Referrer-Policy &quot;strict-origin-when-cross-origin&quot;\n  Header always set Permissions-Policy &quot;camera=(), microphone=(), geolocation=(self)&quot;\n  # Minimal CSP example \u2013 adjust to your site\n  Header set Content-Security-Policy &quot;default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';&quot;\n&lt;\/IfModule&gt;\n<\/code><\/pre>\n<p>Notes:<\/p>\n<ul>\n<li><strong>Use double quotes<\/strong> around header values and escape any inner quotes with <code>'<\/code> if needed.<\/li>\n<li><strong>Place rules near the top<\/strong> of the file, before complex rewrite rules, to make them easier to maintain.<\/li>\n<li>If your panel or a plugin already sets headers, avoid duplicating them. Duplicate headers can confuse browsers.<\/li>\n<\/ul>\n<h3><span id=\"2_Testing_on_Shared_Hosting\">2. Testing on Shared Hosting<\/span><\/h3>\n<p>After editing <code>.htaccess<\/code>, test your site:<\/p>\n<ul>\n<li>Open your site in Chrome\/Firefox, press F12, and check the <strong>Network<\/strong> tab. Click the main request and inspect the <strong>Response Headers<\/strong>.<\/li>\n<li>Use a tool like <code>curl -I https:\/\/example.com<\/code> from a terminal to see headers quickly.<\/li>\n<li>Optionally, use online scanners (like security header checkers) to get a grade and suggestions.<\/li>\n<\/ul>\n<p>If you see 500 errors after editing <code>.htaccess<\/code>, there is usually a syntax issue. Comment out the last changes and re\u2011add them step by step.<\/p>\n<h3><span id=\"3_Panel-Level_Header_Settings\">3. Panel-Level Header Settings<\/span><\/h3>\n<p>Some control panels allow adding custom headers via a GUI (for example through \u201cAdditional Apache directives\u201d or \u201cHTTP headers\u201d sections). Under the hood, these usually inject the same <code>Header set<\/code> directives into the vhost configuration. The rules are the same:<\/p>\n<ul>\n<li>Avoid duplicate headers or conflicting values.<\/li>\n<li>Test changes first on a staging or test subdomain. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-staging-ortami-kurmak-adim-adim-uygulamali-rehber\/\">setting up a WordPress staging environment on shared hosting<\/a> is very handy here.<\/li>\n<\/ul>\n<h2><span id=\"Configuring_Security_Headers_on_a_VPS_Nginx_Apache\">Configuring Security Headers on a VPS (Nginx &amp; Apache)<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"1_Nginx_Examples\">1. Nginx Examples<\/span><\/h3>\n<p>Add these directives inside your <code>server { ... }<\/code> block, preferably in a common include file you reuse across sites:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">add_header Strict-Transport-Security &quot;max-age=31536000; includeSubDomains; preload&quot; always;\nadd_header X-Frame-Options &quot;SAMEORIGIN&quot; always;\nadd_header X-Content-Type-Options &quot;nosniff&quot; always;\nadd_header Referrer-Policy &quot;strict-origin-when-cross-origin&quot; always;\nadd_header Permissions-Policy &quot;camera=(), microphone=(), geolocation=(self)&quot; always;\nadd_header Content-Security-Policy &quot;default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';&quot; always;\n<\/code><\/pre>\n<p>Key points:<\/p>\n<ul>\n<li>Use <code>always<\/code> so headers are added even on 4xx\/5xx error responses.<\/li>\n<li>If you serve static files from a different server block or location, ensure headers apply there too (e.g. in <code>location \/<\/code> or via an <code>include security-headers.conf;<\/code> file).<\/li>\n<li>After changes, run <code>nginx -t<\/code> to test configuration, then <code>systemctl reload nginx<\/code>.<\/li>\n<\/ul>\n<h3><span id=\"2_Apache_on_a_VPS\">2. Apache on a VPS<\/span><\/h3>\n<p>On a VPS, you can define headers in vhost config files instead of <code>.htaccess<\/code>. That is more efficient and easier to manage in version control.<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">&lt;VirtualHost *:443&gt;\n  ServerName example.com\n  ...\n  &lt;IfModule mod_headers.c&gt;\n    Header always set Strict-Transport-Security &quot;max-age=31536000; includeSubDomains; preload&quot;\n    Header always set X-Frame-Options &quot;SAMEORIGIN&quot;\n    Header always set X-Content-Type-Options &quot;nosniff&quot;\n    Header always set Referrer-Policy &quot;strict-origin-when-cross-origin&quot;\n    Header always set Permissions-Policy &quot;camera=(), microphone=(), geolocation=(self)&quot;\n    Header set Content-Security-Policy &quot;default-src 'self'; img-src 'self' data: https:; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self' data: https:; frame-ancestors 'self';&quot;\n  &lt;\/IfModule&gt;\n&lt;\/VirtualHost&gt;\n<\/code><\/pre>\n<p>Then reload Apache: <code>systemctl reload httpd<\/code> or <code>systemctl reload apache2<\/code> depending on your distro.<\/p>\n<p>If you are new to VPS hardening, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening checklist<\/a> pairs nicely with security header work.<\/p>\n<h3><span id=\"3_Reverse_Proxy_and_CDN_Layers\">3. Reverse Proxy and CDN Layers<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li><strong>Origin\u2011side headers<\/strong>: More portable if you change CDN later; your config lives with the app.<\/li>\n<li><strong>CDN\u2011side headers<\/strong>: Can be easier to tweak and test, but be careful not to shadow or override origin headers unexpectedly.<\/li>\n<\/ul>\n<p>Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-guvenlik-ayarlari-rehberi-kucuk-isletme-siteleri-icin-waf-rate-limit-ve-bot-korumasi\/\">Cloudflare security settings guide<\/a> shows how to combine WAF rules with origin\u2011side security headers for a layered defence.<\/p>\n<h2><span id=\"Testing_Monitoring_and_Rolling_Out_Safely\">Testing, Monitoring and Rolling Out Safely<\/span><\/h2>\n<p>Security headers are easy to misconfigure, especially CSP and HSTS. A disciplined rollout avoids production surprises.<\/p>\n<h3><span id=\"Step_1_Start_in_Report-Only_Mode_for_CSP\">Step 1: Start in Report-Only Mode (for CSP)<\/span><\/h3>\n<p>On your staging site or a low\u2011risk domain, start CSP in <code>Content-Security-Policy-Report-Only<\/code> mode. You can configure <code>report-uri<\/code> or <code>report-to<\/code> directives to send violation reports to a service or your own endpoint. Once the reports look clean (no unexpected blocked resources), switch to enforcing <code>Content-Security-Policy<\/code>.<\/p>\n<h3><span id=\"Step_2_Enable_HSTS_Gradually\">Step 2: Enable HSTS Gradually<\/span><\/h3>\n<p>Begin with a small <code>max-age<\/code> (e.g. one day), ensure all HTTP &rarr; HTTPS redirects behave correctly and that no mixed content warnings appear. Then increase to 30 days, 6 months, and only later consider <code>preload<\/code>.<\/p>\n<p>If you are unsure whether your site is fully HTTPS\u2011clean, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ssl-sonrasi-mixed-content-ve-guvensiz-icerik-hatalarini-duzeltmek\/\">fixing mixed content and insecure HTTP requests after enabling SSL<\/a> is a useful checklist.<\/p>\n<h3><span id=\"Step_3_Automate_Checks\">Step 3: Automate Checks<\/span><\/h3>\n<p>For important sites (e\u2011commerce, SaaS, client portals), add header checks into your monitoring:<\/p>\n<ul>\n<li>Use a simple script with <code>curl -I<\/code> to verify key headers and run it via cron.<\/li>\n<li>Integrate basic header validation into your CI\/CD pipeline so new deployments do not accidentally remove or weaken policies.<\/li>\n<li>Combine with uptime and SSL expiry monitoring. Our guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitesi-uptime-izleme-ve-alarm-kurma-rehberi\/\">website uptime monitoring and alerting<\/a> can be extended with header checks as well.<\/li>\n<\/ul>\n<h2><span id=\"Common_Pitfalls_We_See_on_dchostcom_Servers\">Common Pitfalls We See on dchost.com Servers<\/span><\/h2>\n<p>After auditing many real\u2011world sites, a few patterns keep appearing. Being aware of them will save you time.<\/p>\n<h3><span id=\"1_Aggressive_HSTS_on_HalfMigrated_Domains\">1. Aggressive HSTS on Half\u2011Migrated Domains<\/span><\/h3>\n<p>A site enables HSTS with <code>includeSubDomains; preload<\/code> 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.<\/p>\n<h3><span id=\"2_Overly_Strict_CSP_That_Breaks_Admin_Panels\">2. Overly Strict CSP That Breaks Admin Panels<\/span><\/h3>\n<p>Another frequent case: a very strict <code>script-src 'self'<\/code> policy without nonces\/hashes on a WordPress or Laravel admin area that uses inline scripts or third\u2011party resources. Admin pages partially load, but buttons stop working or AJAX calls silently fail. Start with report\u2011only mode and gradually tighten.<\/p>\n<h3><span id=\"3_X-Frame-Options_Blocking_Legitimate_Integrations\">3. X-Frame-Options Blocking Legitimate Integrations<\/span><\/h3>\n<p>We regularly see <code>X-Frame-Options: DENY<\/code> 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 <code>frame-ancestors<\/code> and allow only the exact domains you trust.<\/p>\n<h3><span id=\"4_Conflicting_Headers_from_Multiple_Layers\">4. Conflicting Headers from Multiple Layers<\/span><\/h3>\n<p>Headers set in three places (application, server config, CDN) often conflict. For example, the app sets a lenient <code>Referrer-Policy<\/code>, the CDN sets a strict one, and debugging becomes confusing. Decide where each header should live and keep your configuration DRY.<\/p>\n<h2><span id=\"Example_Header_Sets_for_Common_Hosting_Scenarios\">Example Header Sets for Common Hosting Scenarios<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"1_Small_Brochure_Site_on_Shared_Hosting\">1. Small Brochure Site on Shared Hosting<\/span><\/h3>\n<p>Goal: solid protection with minimal risk of breaking things.<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">Strict-Transport-Security: max-age=31536000;\nX-Frame-Options: SAMEORIGIN\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\nPermissions-Policy: camera=(), microphone=(), geolocation=(self)\nContent-Security-Policy: \n  default-src 'self'; \n  img-src 'self' data: https:; \n  script-src 'self'; \n  style-src 'self' 'unsafe-inline'; \n  font-src 'self' data: https:; \n  frame-ancestors 'self';\n<\/code><\/pre>\n<p>Apply this via <code>.htaccess<\/code> and test forms and contact widgets thoroughly.<\/p>\n<h3><span id=\"2_WordPress_Blog_on_Shared_Hosting_or_VPS\">2. WordPress Blog on Shared Hosting or VPS<\/span><\/h3>\n<p>Goal: balance flexibility (plugins, themes) with improved security.<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">Strict-Transport-Security: max-age=31536000; includeSubDomains\nX-Frame-Options: SAMEORIGIN\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\nPermissions-Policy: camera=(), microphone=(), geolocation=(self)\nContent-Security-Policy: \n  default-src 'self'; \n  img-src 'self' data: https:; \n  script-src 'self' https:\/\/www.googletagmanager.com; \n  style-src 'self' 'unsafe-inline'; \n  font-src 'self' data: https:; \n  connect-src 'self'; \n  frame-ancestors 'self';\n<\/code><\/pre>\n<p>Then, iteratively tighten <code>script-src<\/code> and remove <code>'unsafe-inline'<\/code> as you refactor custom code. Combine this with the hardening steps in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-guvenligi-eklentiler-waf-2fa-ve-yedekler\/\">WordPress security guide on shared hosting<\/a>.<\/p>\n<h3><span id=\"3_ECommerce_or_Login-Heavy_App_on_a_VPS\">3. E\u2011Commerce or Login-Heavy App on a VPS<\/span><\/h3>\n<p>Goal: stronger guarantees and a path towards compliance (PCI\u2011DSS, etc.).<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">Strict-Transport-Security: max-age=31536000; includeSubDomains; preload\nX-Frame-Options: SAMEORIGIN\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\nPermissions-Policy: camera=(), microphone=(), geolocation=(self), payment=(self)\nContent-Security-Policy: \n  default-src 'self'; \n  img-src 'self' data: https:; \n  script-src 'self' 'nonce-...'; \n  style-src 'self'; \n  font-src 'self' data: https:; \n  connect-src 'self' https:\/\/api.payment-gateway.com; \n  frame-ancestors 'self' https:\/\/trusted-partner.com;\n<\/code><\/pre>\n<p>This kind of configuration usually goes together with stricter cookie flags, WAF rules and secure deployment pipelines. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/pci-dss-uyumlu-e-ticaret-hosting-rehberi\/\">PCI\u2011DSS compliant e\u2011commerce hosting<\/a> dives into that wider context.<\/p>\n<h2><span id=\"Conclusion_Turn_Security_Headers_into_a_Normal_Part_of_Your_Stack\">Conclusion: Turn Security Headers into a Normal Part of Your Stack<\/span><\/h2>\n<p>HTTP security headers are not just for huge platforms; they are a low\u2011cost, high\u2011impact layer that every shared hosting and VPS site can (and should) use. HSTS makes HTTPS the default, CSP gives you fine\u2011grained control over what the browser loads, X\u2011Frame\u2011Options and <code>frame-ancestors<\/code> stop clickjacking, and supporting headers like Referrer\u2011Policy, Permissions\u2011Policy and X\u2011Content-Type\u2011Options close off many subtle attack paths.<\/p>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-ve-digerlerini-ne-zaman-nasil-uygulamalisin\/\">friendly HTTP security headers checklist<\/a> 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\u2019s real\u2011world protection.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>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\u2011in protections they already have for your visitors. In this [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4774,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4773","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4773"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4773\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4774"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}