How to Check Security Headers

In today's digital landscape, website security is paramount. Beyond firewalls and encryption, HTTP security headers act as a crucial first line of defense, instructing web browsers on how to behave when interacting with your site. Properly configured security headers can significantly mitigate common web vulnerabilities like Cross-Site Scripting (XSS), clickjacking, MIME-sniffing, and downgrade attacks.

This comprehensive guide will walk you through the process of how to check security headers for any website. Whether you're a web developer, a site owner, or a security professional, understanding and verifying these headers is a fundamental step in maintaining a robust security posture. We'll cover both quick, user-friendly online tools and more advanced command-line methods, ensuring you have all the knowledge to perform a thorough security header check.

By the end of this tutorial, you'll not only know how to perform a security header check but also understand what each critical header means and how to interpret your results to identify potential weaknesses.

Quick Method: Use Secably's Free HTTP Headers Analyzer

The fastest, easiest, and most recommended way to perform a comprehensive security header check is by using Secably's free online HTTP Headers Analyzer. This tool is designed for simplicity and efficiency, providing detailed insights without requiring any installation or signup.

Here's how to use it:

1. Navigate to the Tool: Open your web browser and go to Secably's HTTP Headers Analyzer.
2. Enter Your Target: In the input field, enter the full URL (e.g., https://www.example.com) or IP address of the website you wish to scan. Ensure you include https:// for secure sites.
3. Initiate the Scan: Click the 'Scan' or 'Analyze' button.
4. Review Results: The tool will quickly fetch the HTTP response headers and present them in an easy-to-read format, highlighting key security headers and their configurations.

Secably's HTTP Headers Analyzer provides a clear overview of your website's security header status, including specific checks for critical headers like Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, and more. You'll get results in under 60 seconds, making it an ideal solution for quick audits and regular monitoring.

Manual Method: Command-Line Tools

For advanced users, developers, or those who prefer direct interaction with server responses, command-line tools offer a powerful way to check security headers. These methods provide raw output, which can be useful for scripting or integrating into automated workflows.

1. Using cURL (Recommended for Headers)

cURL is a versatile command-line tool for transferring data with URLs. It's excellent for fetching HTTP headers directly.

Understanding Your Results

Once you've run a scan using either Secably's tool or a command-line method, it's crucial to understand what the various security headers mean and how to interpret their values. Here's a breakdown of the most important security headers you should look for:

1. Strict-Transport-Security (HSTS)

Purpose: Forces browsers to interact with your website only over HTTPS, preventing downgrade attacks and cookie hijacking. It tells the browser to automatically convert all future HTTP requests for your domain into HTTPS requests for a specified period.

Example (Good): Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: The time (in seconds) the browser should remember to only use HTTPS. A year (31536000 seconds) is common.
• includeSubDomains: Applies the HSTS policy to all subdomains.
• preload: Allows your domain to be submitted to the HSTS preload list, which is hardcoded into major browsers.

What to look for: Presence of the header, a sufficiently high max-age, and ideally includeSubDomains and preload.

2. Content-Security-Policy (CSP)

Purpose: Mitigates Cross-Site Scripting (XSS) and other code injection attacks by specifying which dynamic resources (scripts, stylesheets, images, etc.) are allowed to be loaded and executed by the browser.

Example (Good): Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests; block-all-mixed-content;

• default-src: Fallback for any fetch directives not specified. 'self' restricts resources to the same origin.
• script-src: Defines valid sources for JavaScript.
• object-src: Defines valid sources for <object>, <embed>, or <applet> elements. 'none' is often recommended.
• frame-ancestors: Restricts which URLs can embed the current page in a frame.
• upgrade-insecure-requests: Instructs browsers to rewrite HTTP URLs to HTTPS.
• report-uri or report-to: (Optional) Specifies a URL to which the browser sends reports when a CSP violation occurs.

What to look for: A well-defined CSP that restricts resources to trusted sources, avoiding `'unsafe-inline'` and `'unsafe-eval'` where possible.

3. X-Frame-Options

Purpose: Prevents clickjacking attacks by controlling whether your page can be embedded in a <frame>, <iframe>, <embed>, or <object>.

Example (Good): X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN

• DENY: The page cannot be displayed in a frame, regardless of the site attempting to do so.
• SAMEORIGIN: The page can only be displayed in a frame on the same origin as the page itself.

What to look for: Presence of this header with either DENY or SAMEORIGIN. Note that CSP's frame-ancestors directive is a more modern and flexible alternative, but X-Frame-Options is still widely supported.

4. X-Content-Type-Options

Purpose: Prevents browsers from MIME-sniffing a response away from the declared Content-Type. This mitigates attacks where an attacker might upload a malicious file (e.g., a JavaScript file disguised as an image) that the browser would then execute.

Example (Good): X-Content-Type-Options: nosniff

What to look for: The presence of nosniff.

5. Referrer-Policy

Purpose: Controls how much referrer information (the origin of the request) is sent with requests initiated from your document.

Example (Good): Referrer-Policy: no-referrer-when-downgrade or Referrer-Policy: same-origin

• no-referrer-when-downgrade: Sends the full URL when the protocol security level stays the same or improves (HTTP to HTTPS), but no referrer when downgrading (HTTPS to HTTP).
• same-origin: Sends the full URL for same-origin requests, but no referrer for cross-origin requests.

What to look for: A policy that balances privacy and functionality, preventing sensitive information leakage.

6. Permissions-Policy (formerly Feature-Policy)

Purpose: Allows a website to explicitly allow or deny the use of browser features (e.g., camera, microphone, geolocation, fullscreen) for itself and for any embedded iframes.

Example (Good): Permissions-Policy: geolocation=(self "https://example.com"), camera=()

What to look for: Policies that restrict unnecessary features, enhancing user privacy and security.

7. Cross-Origin-Opener-Policy (COOP) and Cross-Origin-Embedder-Policy (COEP)

Purpose: These headers are crucial for isolating your document from cross-origin windows and preventing it from loading cross-origin resources that don't explicitly grant permission via CORS or CORP headers. They are key components for enabling powerful features like SharedArrayBuffer.

Example (Good): Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp

What to look for: For high-security applications or those using advanced browser features, these headers should be present and correctly configured.

Common Issues & Troubleshooting

When you check security headers, you might encounter several common issues. Here’s how to identify and troubleshoot them:

• Missing Headers: The most common issue is the complete absence of critical security headers. This means your website is not instructing browsers to enforce these security policies, leaving it vulnerable.
• Incorrect Syntax or Values: Even if a header is present, a typo, incorrect value, or missing semicolon can render it ineffective. For example, an overly permissive CSP (e.g., using `'unsafe-inline'`) can negate its security benefits.
• CDN or Proxy Interference: Content Delivery Networks (CDNs) or reverse proxies can sometimes strip or modify headers. Ensure your CDN or proxy is configured to pass through or add the correct security headers.
• Caching Issues: If you've recently updated your server configuration, old headers might still be served from a cache. Clear your server cache, CDN cache, and browser cache, then re-check.
• Server Configuration Errors: Headers are typically set in your web server's configuration (Apache, Nginx, IIS) or via your application code. Errors in these configurations can prevent headers from being sent.
• Firewall Blocking Scans: While less common for simple header checks, aggressive firewalls or WAFs might block requests from unknown IP addresses, especially if you're using a custom script or a less-known online tool. Secably's tool uses a distributed network to minimize this risk.
• Mixed Content Warnings: While not a header issue directly, if your site uses HTTPS but loads some resources over HTTP, browsers will show mixed content warnings. HSTS and CSP's upgrade-insecure-requests and block-all-mixed-content directives help mitigate this.

Always re-scan after making changes to verify that your headers are correctly implemented.

Next Steps

Finding issues with your security headers is the first step; fixing them is the next crucial one. Here's what to do after identifying vulnerabilities:

1. Implement or Correct Headers

The method for adding or modifying security headers depends on your web server or application framework:

• Apache: Use mod_headers in your .htaccess file or main configuration (httpd.conf). Example: Header always set X-Frame-Options "SAMEORIGIN"
• Nginx: Use the add_header directive in your server block within nginx.conf. Example: add_header X-Frame-Options "DENY";
• IIS: Modify your web.config file to add custom headers.
• Node.js/Express: Use middleware like Helmet.js.
• PHP: Use the header() function at the top of your scripts.
• CMS Platforms (WordPress, Joomla, etc.): Many CMS platforms offer security plugins that allow you to manage security headers without direct server configuration.

Always test changes in a staging environment first and clear caches before deploying to production.

2. Continuous Monitoring

Security is an ongoing process. Regularly check security headers, especially after any website updates, server migrations, or changes to your CDN configuration. Automated tools like Secably's HTTP Headers Analyzer make this process quick and efficient.

3. Further Security Testing

Security headers are just one layer of defense. To ensure comprehensive protection, consider performing additional security assessments:

• Run a full vulnerability scan: Use Secably's Website Scanner to identify a broader range of vulnerabilities, including outdated software, misconfigurations, and common web application flaws.
• Check all open ports: Use Secably's Port Scanner to discover which ports are open on your server and what services are running on them, helping you minimize your attack surface.
• Discover all subdomains: Attackers often target less-secured subdomains. Use Secably's Subdomain Finder to ensure all your subdomains are accounted for and secured.

By taking these next steps, you can significantly enhance your website's overall security posture and protect your users from various online threats.

Is Secably's HTTP Headers Analyzer free?

Yes, Secably's HTTP Headers Analyzer is completely free for basic scans with no signup required. You can use it as often as you need to check your website's security headers.

Is it safe to scan my own website?

Yes, scanning your own assets (websites, servers, IPs) is legal, safe, and highly recommended as part of routine security hygiene. It helps you identify vulnerabilities before malicious actors do.

How often should I check my security headers?

We recommend scanning at least monthly, or after any significant infrastructure changes, website updates, or deployment of new features. Regular checks ensure that new configurations haven't inadvertently removed or misconfigured existing headers.

What if I see different headers on different pages?

This can happen due to several reasons: specific page configurations, different server settings for subdirectories, or caching mechanisms. Ensure your security headers are consistently applied across your entire domain, especially on critical pages.

Do security headers replace other security measures?

No, security headers are an important layer of defense but do not replace other essential security measures like strong passwords, regular software updates, firewalls, secure coding practices, and SSL/TLS encryption. They work in conjunction with these measures to provide comprehensive protection.