What Are Security Headers? Check Your HTTP Headers for Free

Security headers are a set of HTTP response headers that tell the browser how to handle your content securely. Without the right security headers, your website becomes vulnerable to attacks like cross-site scripting (XSS), clickjacking, and MIME type sniffing. The good news: adding them requires no code changes — just a few lines in your .htaccess or Nginx config.

This guide explains the most important security headers, shows you how to check your current grade for free, and walks through adding them to Apache or Nginx hosting.

Key Security Headers Every Website Should Have

Check Your Security Headers Instantly (Free)

Before adding headers, run a quick check to see what your site already sends and what's missing. A free online tool that gives detailed, easy-to-understand results:

Understanding the Grade System

Security header checkers typically score your site from A+ to F based on which headers are present and how well they're configured:

Most unconfigured sites score D or F. A good target is B+ or higher. For e-commerce, banking, or login-based sites, aim for A+.

Adding Security Headers in .htaccess (Apache / DirectAdmin)

On Apache-based hosting — including AsiaGB's DirectAdmin hosting — add security headers to your root .htaccess file:

# Security Headers — add to .htaccess
<IfModule mod_headers.c>
    # Force HTTPS for 1 year
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" "expr=%{HTTPS} == 'on'"

    # Prevent clickjacking
    Header always set X-Frame-Options "SAMEORIGIN"

    # Prevent MIME sniffing
    Header always set X-Content-Type-Options "nosniff"

    # Referrer policy
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Disable camera/mic/geo
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

    # Legacy XSS protection
    Header always set X-XSS-Protection "1; mode=block"
</IfModule>

Adding Security Headers in Nginx (VPS)

On a VPS running Nginx, add these headers inside the server block of your site configuration:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" 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 "geolocation=(), microphone=(), camera=()" always;
add_header X-XSS-Protection "1; mode=block" always;

Testing Security Headers on Staging Before Going Live

Before pushing security headers to a production server, test them on a staging environment first — especially CSP, which is the most likely to break functionality. Here is a reliable testing workflow:

1. Check browser DevTools Console: After adding headers, open the Console tab (F12) and look for "Refused to load" or "Blocked by Content Security Policy" messages.
2. Start with Report-Only mode: Use Content-Security-Policy-Report-Only to monitor violations without blocking anything. Run it for at least two to four days to catch edge cases.
3. Test every feature path: Exercise all site functionality — forms, embedded videos, maps, payment widgets, login flows — since each may require different source allowances in CSP.
4. Test on mobile: Some mobile browsers interpret CSP directives slightly differently. Test on both iOS Safari and Android Chrome at minimum.
5. Verify live with a checker: After deploying to production, re-run dnsxray.com/security-headers to confirm the headers are actually being served correctly.

Security Headers Across Platforms: Apache, Nginx, and Frameworks

The method for setting security headers depends on your hosting stack. Here is a quick reference for the most common environments:

Understanding Content-Security-Policy in Depth

Content-Security-Policy (CSP) is the most powerful — and most complex — security header. It tells the browser exactly which sources are allowed to load scripts, styles, images, fonts, and other resources. A well-crafted CSP makes XSS attacks significantly harder to execute because even if an attacker injects a script tag, the browser will refuse to run it if the source isn't whitelisted.

Core CSP Directives

• default-src — Fallback for any directive not explicitly set
• script-src — Allowed sources for JavaScript files
• style-src — Allowed sources for CSS files
• img-src — Allowed sources for images
• connect-src — Allowed endpoints for Fetch, XHR, and WebSocket connections
• frame-ancestors — Controls which pages can embed your site in an iframe (replaces X-Frame-Options)

Sample CSP for a Site Using Google Analytics and Google Fonts

# Sample CSP — customize for your site
Header always set Content-Security-Policy \
  "default-src 'self'; \
   script-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://www.google-analytics.com; \
   style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; \
   font-src 'self' https://fonts.gstatic.com; \
   img-src 'self' data: https://www.google-analytics.com; \
   connect-src 'self' https://www.google-analytics.com; \
   frame-ancestors 'self';"

Security Header Impact Comparison

Each security header protects against different attack vectors. Understanding the risk of missing each one helps you prioritize what to implement first:

HSTS Preload: Long-Term Commitment You Must Understand

HSTS Preload means registering your domain in a hardcoded list that Chrome, Firefox, Safari, and Edge ship in their source code. The browser enforces HTTPS before making any network request — even on a first visit — because it already knows your site requires it.

Requirements before submitting to the HSTS Preload list at hstspreload.org:

• A valid SSL certificate covering all subdomains
• Strict-Transport-Security header with max-age of at least 31536000 (one year)
• The includeSubDomains directive present
• The preload directive present
• All HTTP requests redirect to HTTPS first

Common Problems After Adding Security Headers

Implementing security headers sometimes breaks functionality. Here are the most common issues and how to fix them:

1. White Screen After Adding CSP

The most common cause is CSP blocking a required script or stylesheet. Open browser DevTools (F12), check the Console tab, and look for "Refused to load..." errors. Each error will include the blocked URL — add that domain to the appropriate CSP directive.

2. External Images or Videos Not Displaying

Verify that img-src and media-src in your CSP include the domains hosting those assets. For example, if you serve images from a CDN, that CDN domain must be explicitly listed.

3. Google Analytics or Tracking Tags Stop Working

Add tracking platform domains to both script-src and connect-src:

script-src 'self' 'unsafe-inline'
  https://www.googletagmanager.com
  https://connect.facebook.net;
connect-src 'self'
  https://www.google-analytics.com
  https://www.facebook.com;

4. HSTS Prevents HTTP Access During Development

This is expected behavior — browsers that have seen an HSTS header will refuse HTTP connections for the max-age duration. For local testing, use an Incognito window, or clear HSTS state in Chrome at chrome://net-internals/#hsts.

Security Headers for WordPress

Add headers to your root .htaccess above the # BEGIN WordPress block (WordPress rewrites below that marker when you save Permalinks). Alternatively, use a plugin:

• WP Rocket — Security headers available under Advanced Rules
• Wordfence — Extended Protection includes header configuration
• Headers Security Advanced & HSTS WP — Dedicated security header management plugin

Step-by-Step: Using dnsxray.com to Check Headers

1. Open dnsxray.com/security-headers
2. Enter your website URL (e.g., https://yourdomain.com) and click Check
3. View your overall grade plus the status of each individual header
4. Missing headers show specific fix instructions
5. After adding headers to .htaccess or Nginx, re-check to confirm the grade improved

Frequently Asked Questions