Analyze HTTP response headers and check security headers configuration
HTTP security headers are response headers that tell browsers how to behave when handling your website's content. They're crucial for protecting against common web vulnerabilities and attacks. Implementing these headers is free and significantly improves security.
Security headers provide defense-in-depth protection:
Purpose: Forces browsers to only connect via HTTPS, preventing protocol downgrade attacks and cookie hijacking.
Example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Why important: Prevents man-in-the-middle attacks by ensuring all connections use HTTPS.
Best practice: Set max-age to at least 1 year (31536000 seconds), include subdomains.
Purpose: Controls which resources can be loaded, preventing XSS and data injection attacks.
Example: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
Why important: Most effective defense against XSS attacks. Can prevent malicious scripts from executing.
Best practice: Start with restrictive policy, gradually allow necessary sources. Avoid 'unsafe-inline' if possible.
Purpose: Prevents your site from being embedded in iframes, protecting against clickjacking attacks.
Example: X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN
Why important: Attackers use iframes to trick users into clicking hidden elements.
Best practice: Use DENY unless you need iframe embedding, then use SAMEORIGIN.
Purpose: Prevents browsers from MIME-sniffing content types, reducing security risks.
Example: X-Content-Type-Options: nosniff
Why important: Prevents browsers from interpreting files as different type than declared.
Best practice: Always set to "nosniff".
Purpose: Enables browser's built-in XSS filter (legacy, CSP is preferred).
Example: X-XSS-Protection: 1; mode=block
Why important: Provides additional XSS protection in older browsers.
Best practice: Set to "1; mode=block" but prioritize CSP for modern protection.
Purpose: Controls how much referrer information is sent with requests.
Example: Referrer-Policy: strict-origin-when-cross-origin
Why important: Prevents leaking sensitive URL information to third parties.
Best practice: Use "strict-origin-when-cross-origin" or "no-referrer" for sensitive sites.
Purpose: Controls which browser features and APIs can be used.
Example: Permissions-Policy: geolocation=(), microphone=(), camera=()
Why important: Limits potential abuse of browser features.
Best practice: Disable features you don't need.
Server: Reveals web server type and version. Consider hiding or limiting information.
X-Powered-By: Exposes technology stack (e.g., PHP version). Should be removed.
X-AspNet-Version: Reveals ASP.NET version. Should be removed.
Apache (.htaccess):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "DENY"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self'"
Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
IIS (web.config):
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000" />
<add name="X-Frame-Options" value="DENY" />
</customHeaders>
</httpProtocol>
Use our tool to check your headers after implementation. Also check:
curl -I https://yoursite.comCheck all critical security headers and get security score
Identify missing security headers and vulnerabilities
Get specific recommendations to improve security
HTTP security headers are response headers sent by web servers to browsers that instruct them how to handle security aspects of your website. They provide defense-in-depth protection against common web vulnerabilities. Key headers include: Strict-Transport-Security (HSTS) which forces HTTPS, Content-Security-Policy (CSP) which prevents XSS attacks, X-Frame-Options which prevents clickjacking, and X-Content-Type-Options which prevents MIME sniffing. These headers are free to implement and provide significant security improvements without requiring code changes.
HSTS (HTTP Strict Transport Security) is a security header that forces browsers to only connect to your website over HTTPS, never HTTP. Header format: Strict-Transport-Security: max-age=31536000; includeSubDomains. Why crucial: (1) Prevents protocol downgrade attacks where attackers force HTTP connection, (2) Protects against cookie hijacking, (3) Eliminates need for HTTP→HTTPS redirects, (4) Google Chrome includes HSTS preload list for extra protection. Best practice: Set max-age to at least 1 year, include subdomains, consider HSTS preload submission. Only use if your entire site supports HTTPS.
Content Security Policy is a powerful security header that controls which resources (scripts, styles, images, etc.) can be loaded on your website. It's the most effective defense against XSS (Cross-Site Scripting) attacks. Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com allows resources only from your domain and specified CDN. Benefits: Prevents malicious script execution, blocks inline JavaScript (major XSS vector), controls resource loading, reports violations. Implementation tip: Start with report-only mode (Content-Security-Policy-Report-Only) to test without breaking functionality.
Clickjacking (UI redressing) tricks users into clicking elements on your site that are hidden within an iframe. Protection method: Use X-Frame-Options header. Options: (1) X-Frame-Options: DENY - prevents all iframe embedding (most secure), (2) X-Frame-Options: SAMEORIGIN - allows embedding only from same domain. Modern alternative: Use CSP frame-ancestors directive: Content-Security-Policy: frame-ancestors 'none' or frame-ancestors 'self'. Frame-ancestors is more flexible and is the recommended approach, but X-Frame-Options provides backward compatibility with older browsers.
Yes! The Server header reveals your web server type and version (e.g., Server: Apache/2.4.41 (Ubuntu)). Security risk: Attackers use this info to identify known vulnerabilities in specific versions. Best practice: Remove version information or hide header completely. How to hide: Apache: ServerTokens Prod and ServerSignature Off in config. Nginx: server_tokens off;. Also remove X-Powered-By header which reveals PHP, ASP.NET, or other technology versions. While "security through obscurity" isn't sufficient alone, limiting information disclosure is good practice.
MIME sniffing occurs when browsers ignore the declared Content-Type and try to determine file type by examining content. Security risk: Attackers can disguise malicious JavaScript as images or other file types. Browser executes script despite declared type. Prevention: Use X-Content-Type-Options: nosniff header to force browsers to respect declared Content-Type. Impact: Prevents XSS attacks via uploaded files, stops execution of scripts masquerading as other types. Always use: This header has no downsides and should always be set to "nosniff" on all responses.
Implementation depends on your web server: Apache: Add headers to .htaccess or httpd.conf using Header set or Header always set directives. Nginx: Use add_header directive in server or location blocks (add "always" flag to ensure headers appear even on error pages). IIS: Configure in web.config using customHeaders section. Application-level: Set headers in your code (PHP: header(), Node.js: res.setHeader()). CDN/Proxy: Configure headers at Cloudflare, AWS CloudFront, or other CDN. Testing: After implementation, verify using our tool or curl: curl -I https://yoursite.com
Security header scores vary by tool, but generally: A grade (90-100): Excellent security with all critical headers properly configured. B grade (80-89): Good security, missing some optional headers. C grade (70-79): Acceptable but needs improvement. D/F grade (below 70): Poor security, missing critical headers. Minimum recommendations: At minimum, implement HSTS (if using HTTPS), X-Frame-Options, X-Content-Type-Options, and CSP. These four headers provide substantial protection. Perfect score: Not always necessary - implement headers appropriate for your site's needs. Some headers may not apply to all sites.
Yes, if improperly configured, especially CSP. Common issues: (1) CSP too restrictive: Blocks legitimate scripts, breaks functionality. (2) HSTS without full HTTPS: If any page doesn't support HTTPS, users can't access it. (3) X-Frame-Options breaks legitimate iframes: If you need iframe embedding. Safe implementation: (1) Test in staging environment first, (2) Use CSP in report-only mode initially, (3) Start with permissive policies, gradually restrict, (4) Monitor for errors after deployment, (5) Test thoroughly in all browsers. Recovery: If issues occur, remove problematic header, diagnose issue, adjust configuration, re-test.