How to Check HTTP Headers: A Comprehensive Guide

HTTP headers are a fundamental part of how the web works, carrying vital metadata between web browsers and servers. While often invisible to the average user, these headers play a crucial role in everything from content delivery and caching to, most importantly, web security. Understanding how to check HTTP headers is an essential skill for web developers, security professionals, system administrators, and anyone responsible for a website's integrity.

Misconfigured or missing HTTP headers can expose your website to various vulnerabilities, including Cross-Site Scripting (XSS), Clickjacking, and MIME-sniffing attacks. Conversely, properly configured security headers act as a robust first line of defense, significantly bolstering your site's resilience against common threats.

This comprehensive guide will walk you through multiple methods to perform header analysis, from the quickest and easiest online tools to advanced command-line techniques. We'll also delve into understanding the results, identifying common issues, and taking actionable steps to improve your website's security posture.

Quick Method: Use Secably's Free HTTP Headers Analyzer

For the fastest, easiest, and most user-friendly way to check HTTP headers, we highly recommend Secably's free online HTTP Headers Analyzer. This tool requires no installation, no signup, and delivers comprehensive results in seconds, making it ideal for quick checks and regular monitoring.

Step-by-Step Guide:

1. Navigate to the Tool: Open your web browser and go to Secably's HTTP Headers Analyzer.
2. Enter Your Target: In the provided input field, enter the full URL (e.g., https://www.example.com) or IP address of the website you wish to scan.
3. Initiate Scan: Click the 'Scan' or 'Analyze' button.
4. Review Results: The tool will quickly process your request and display all detected HTTP response headers, often highlighting critical security headers and their configurations.

Why choose Secably's tool?

• Completely Free: No hidden costs or premium features required for basic header analysis.
• No Signup: Get instant results without creating an account or providing personal information.
• Online & Accessible: Use it from any device with an internet connection.
• Fast & Efficient: Results are typically delivered in under 60 seconds.
• User-Friendly Interface: Designed for clarity, making it easy to understand even complex header information.

This method is perfect for website owners, developers, and security enthusiasts who need quick, reliable insights into their website's header configuration without diving into command-line complexities.

Manual Methods: Command-Line Tools & Browser Developer Tools

While online tools offer convenience, understanding how to check HTTP headers manually using command-line tools or browser developer tools provides deeper insights and is invaluable for advanced troubleshooting or scripting. These methods give you direct control over the request and response process.

1. Using Browser Developer Tools (Recommended for Quick Checks)

Most modern web browsers include powerful developer tools that allow you to inspect network activity, including HTTP headers, directly from your browser. This is often the first manual method developers reach for.

1. Open Developer Tools:
• Chrome/Edge/Brave: Right-click anywhere on the webpage and select 'Inspect' or press Ctrl+Shift+I (Windows/Linux) / Cmd+Option+I (macOS).
• Firefox: Right-click and select 'Inspect Element' or press Ctrl+Shift+I (Windows/Linux) / Cmd+Option+I (macOS).
• Safari: Go to Safari > Preferences > Advanced, and check 'Show Develop menu in menu bar'. Then, from the Develop menu, select 'Show Web Inspector' or press Cmd+Option+I.
2. Navigate to Network Tab: Within the developer tools panel, click on the 'Network' tab.
3. Reload the Page: With the Network tab open, reload the webpage (F5 or Cmd+R). You'll see a list of all requests made by the browser.
4. Inspect a Request: Click on the main document request (usually the first one, corresponding to your URL).
5. View Headers: In the right-hand panel, click on the 'Headers' tab. Here you'll find both 'Request Headers' (sent by your browser) and 'Response Headers' (sent by the server).

2. Using curl (Command-Line)

curl is a versatile command-line tool for transferring data with URLs, supporting various protocols, including HTTP. It's excellent for inspecting HTTP headers.

curl -I https://www.example.com

Explanation:

• -I (or --head): This option tells curl to only fetch the HTTP headers, performing a HEAD request instead of a full GET request. This is the quickest way to see just the response headers.

To see both request and response headers (verbose output):

curl -v https://www.example.com

Explanation:

• -v (or --verbose): This option provides a lot more information, including the full request sent by curl, the SSL/TLS handshake details, and all response headers. Lines starting with > are request headers, and lines starting with < are response headers.

3. Using wget (Command-Line)

wget is another popular command-line utility for retrieving content from web servers. It can also be used to inspect headers.

wget -S --spider https://www.example.com

Explanation:

• -S (or --server-response): Prints the server response headers.
• --spider: Tells wget not to download the actual content, just to check if the URL exists. This is similar to curl -I.

4. Using nmap with http-headers script

Nmap, primarily a network scanner, can also be extended with scripts to perform various tasks, including fetching HTTP headers. This is useful if you're already using Nmap for other security assessments.

nmap -p 80,443 --script http-headers example.com

Explanation:

• -p 80,443: Specifies the ports to scan (HTTP and HTTPS).
• --script http-headers: Activates the Nmap Scripting Engine (NSE) script designed to retrieve HTTP headers.
• example.com: The target domain.

5. Using openssl s_client (Advanced for HTTPS)

For a very low-level view of the SSL/TLS handshake and then sending an HTTP request over the secure connection, openssl s_client is the tool. This is particularly useful for debugging SSL/TLS issues alongside HTTP headers.

printf "GET / HTTP/1.0\r\
Host: example.com\r\
\r\
" | openssl s_client -connect example.com:443 -servername example.com

Explanation:

• printf "GET / HTTP/1.0\r\ Host: example.com\r\ \r\ ": Constructs a basic HTTP GET request. The \r\ \r\ is crucial for signaling the end of the request headers.
• |: Pipes the HTTP request into openssl s_client.
• openssl s_client -connect example.com:443: Establishes an SSL/TLS connection to the specified host and port.
• -servername example.com: Essential for Server Name Indication (SNI) when multiple websites share an IP address on the same server.

This command will output a lot of SSL/TLS certificate information first, followed by the HTTP response headers and body.

Understanding Your HTTP Header Analysis Results

Once you've retrieved the HTTP headers, the next crucial step is to understand what they mean. Headers are key-value pairs that provide metadata about the request or response. We'll focus on HTTP response headers, as these are what the server sends back to your browser and are critical for security and functionality.

Common HTTP Response Headers:

• Date: The date and time at which the message was originated.
• Server: Information about the web server software (e.g., Apache, Nginx, IIS). While not directly a security header, it can sometimes be used by attackers to identify potential vulnerabilities in specific server versions. It's often recommended to obfuscate or remove this header.
• Content-Type: Indicates the media type of the resource (e.g., text/html, application/json). Essential for browsers to render content correctly.
• Content-Length: The size of the response body in bytes.
• Last-Modified: The date and time the resource was last modified. Used for caching.
• ETag: An entity tag, a unique identifier for a specific version of a resource. Used for caching.
• Set-Cookie: Used by the server to send cookies to the user agent. Critical for session management, but also a potential vector for session hijacking if not secured (e.g., with HttpOnly and Secure flags).
• Location: Used for redirection (e.g., 301 Moved Permanently, 302 Found).
• Cache-Control, Pragma, Expires: Headers that control caching behavior. Proper caching can improve performance but improper caching can expose sensitive data.

Critical Security Headers (Header Analysis Focus):

These headers are paramount for protecting your website and users from common web vulnerabilities. Ensuring they are correctly implemented is a cornerstone of web security.

• Strict-Transport-Security (HSTS):
  Purpose: Forces browsers to interact with your site only over HTTPS, even if the user types http://. This prevents downgrade attacks and cookie hijacking over insecure connections.
  Example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  What to look for: Presence of the header, a sufficiently long max-age (e.g., 1 year = 31536000 seconds), and ideally includeSubDomains and preload for maximum protection.
• Content-Security-Policy (CSP):
  Purpose: Mitigates Cross-Site Scripting (XSS) and other data injection attacks by specifying which dynamic resources (scripts, styles, images, etc.) are allowed to load and from where.
  Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'
  What to look for: A well-defined policy that restricts sources to only those necessary. A missing CSP or a very permissive one (e.g., default-src *) is a significant security risk.
• X-Frame-Options:
  Purpose: Prevents clickjacking attacks by controlling whether your page can be embedded in an <iframe>, <frame>, or <object>.
  Example: X-Frame-Options: DENY or X-Frame-Options: SAMEORIGIN
  What to look for: Presence of the header with DENY (most secure) or SAMEORIGIN. A missing header allows any site to frame your content.
• X-Content-Type-Options:
  Purpose: Prevents browsers from MIME-sniffing a response away from the declared Content-Type. This helps prevent attacks where an attacker might upload a malicious file disguised as an image, which the browser then executes as a script.
  Example: X-Content-Type-Options: nosniff
  What to look for: Presence of the header with the value nosniff.
• Referrer-Policy:
  Purpose: Controls how much referrer information is sent with requests. This helps protect user privacy by limiting what information is passed to third-party sites.
  Example: Referrer-Policy: no-referrer-when-downgrade or Referrer-Policy: same-origin
  What to look for: A policy that balances privacy and functionality. no-referrer or same-origin are generally good for privacy.
• Permissions-Policy (formerly Feature-Policy):
  Purpose: Allows you to selectively enable or disable various browser features and APIs (e.g., camera, microphone, geolocation) for your own origin and for embedded iframes.
  Example: Permissions-Policy: geolocation=(self "https://example.com"), camera=()
  What to look for: A policy that disables features not needed by your site, especially for third-party content.
• Expect-CT:
  Purpose: Enables Certificate Transparency (CT) enforcement, helping to detect misissued or malicious certificates for your domain.
  Example: Expect-CT: max-age=86400, enforce, report-uri="https://example.com/report"
  What to look for: Presence of the header with max-age and ideally enforce and a report-uri.
• X-XSS-Protection:
  Purpose: Enables the XSS filter built into some browsers. While largely superseded by CSP, it can still provide a layer of defense for older browsers.
  Example: X-XSS-Protection: 1; mode=block
  What to look for: Presence of the header with 1; mode=block. Note: CSP is a more robust solution.

A thorough header analysis involves checking for the presence, correct values, and appropriate configuration of all these headers. Missing or improperly configured security headers are red flags that should be addressed immediately.

Common Issues & Troubleshooting When Checking HTTP Headers

Even with the right tools, you might encounter issues when trying to check HTTP headers. Here are some common problems and how to troubleshoot them:

• Website Not Found / DNS Resolution Failure:
  Symptom: The tool or command returns an error like 'Host not found' or 'Could not resolve host.'
  Troubleshooting: Double-check the URL or IP address for typos. Ensure the domain is correctly registered and its DNS records are propagated. You can use a tool like dig or nslookup to verify DNS resolution (e.g., dig example.com).
• Connection Refused / Timeout:
  Symptom: The tool or command fails to connect, or the request times out.
  Troubleshooting:
  • Firewall: A firewall (on the server or network) might be blocking incoming connections on ports 80 (HTTP) or 443 (HTTPS). Ensure these ports are open.
  • Incorrect Port: Verify you're trying to connect to the correct port. Most web traffic uses 80 for HTTP and 443 for HTTPS.
  • Server Down: The web server might be offline or overloaded. Try accessing the website normally in a browser.
  • IP Address Issues: If using an IP, ensure it's the correct public IP for the web server.
• SSL/TLS Certificate Errors:
  Symptom: When checking HTTPS sites, you might see errors related to invalid, expired, or untrusted certificates.
  Troubleshooting:
  • Certificate Validity: Check the certificate's expiry date and ensure it's issued for the correct domain.
  • Chain of Trust: Ensure the full certificate chain is correctly installed on the server.
  • SNI Issues: If using openssl s_client, ensure you're using the -servername flag for SNI.
• Empty or Incomplete Response:
  Symptom: The tool returns no headers, or only a few basic ones.
  Troubleshooting:
  • Redirects: The initial request might be redirecting to another URL. Some tools (like curl -I) follow redirects by default, but others might not. If using curl, try curl -IL https://www.example.com to see headers for all redirects.
  • Application Logic: The web application itself might be configured to send minimal headers under certain conditions.
  • Load Balancers/Proxies: If your site is behind a load balancer or CDN, the headers you see might be from the proxy, not the origin server. You might need to check specific headers like X-Forwarded-For or Via to identify proxy involvement.
• Unexpected Headers:
  Symptom: You see headers you don't recognize or that seem out of place.
  Troubleshooting: Research the header. It might be added by a CDN, a web application firewall (WAF), a specific server module, or the application itself. While some are harmless, others could indicate misconfigurations or even compromise.

When troubleshooting, always start with the simplest method (like Secably's tool or browser dev tools) and progressively move to more detailed command-line options if the issue persists.

Next Steps After Checking HTTP Headers

Identifying issues with your HTTP headers is just the first step. The real value comes from taking action to remediate vulnerabilities and strengthen your website's security. Here’s what you should do after performing a header analysis:

1. Prioritize and Fix Missing or Misconfigured Security Headers:

Based on your analysis, focus on implementing or correcting the critical security headers first. Here are common ways to implement them:

• Web Server Configuration (Apache/Nginx): Many security headers can be added directly in your web server's configuration files (e.g., .htaccess for Apache, or nginx.conf for Nginx). This is generally the most efficient method as it applies to all content served by the server.
• Application Code: If you have a custom web application, you can set headers within your application's code (e.g., PHP, Node.js, Python, Ruby). This offers fine-grained control but requires careful implementation across all relevant responses.
• CDN/WAF Configuration: If you use a Content Delivery Network (CDN) or a Web Application Firewall (WAF), many providers offer options to configure or inject security headers at their edge, before requests reach your origin server.

Example for Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;\nadd_header X-Frame-Options "DENY" always;\nadd_header X-Content-Type-Options "nosniff" always;\nadd_header Referrer-Policy "no-referrer-when-downgrade" always;\nadd_header Permissions-Policy "geolocation=(), microphone=()" always;

Example for Apache (in .htaccess or httpd.conf):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"\nHeader always set X-Frame-Options "DENY"\nHeader always set X-Content-Type-Options "nosniff"\nHeader always set Referrer-Policy "no-referrer-when-downgrade"\nHeader always set Permissions-Policy "geolocation=(), microphone=()"

2. Re-scan and Verify:

After making changes, always re-scan your website using Secably's HTTP Headers Analyzer or your preferred manual method to ensure the headers are correctly implemented and reflected in the server's responses.

3. Implement Regular Monitoring:

Web environments are dynamic. Changes to server configurations, application updates, or CDN settings can inadvertently alter your HTTP headers. Implement a routine to check HTTP headers regularly (e.g., monthly or after any major deployment) to catch regressions early.

4. Conduct Further Security Testing:

HTTP headers are just one layer of your website's security. A comprehensive security posture requires broader testing. Secably offers additional free tools to help you identify other vulnerabilities:

• Run a full vulnerability scan: Go beyond headers to discover common web application vulnerabilities, misconfigurations, and outdated software.
• Check all open ports: Identify unnecessary open ports that could expose services to attackers.
• Discover all subdomains: Uncover forgotten or unknown subdomains that might host vulnerable applications.

By integrating HTTP header analysis into your regular security routine and leveraging a suite of security tools, you can significantly enhance your website's protection against evolving cyber threats.

Is Secably's HTTP Headers Analyzer free?

Yes, Secably's HTTP Headers Analyzer is completely free to use for basic scans. There's no need to sign up or provide any payment information, making it a convenient and accessible tool for everyone.

Is it safe to scan my own website?

Absolutely. Scanning your own website or any assets you own and manage is not only safe but highly recommended as a fundamental part of your security hygiene. It helps you proactively identify and fix vulnerabilities before malicious actors can exploit them.

How often should I check my HTTP headers?

We recommend checking your HTTP headers at least monthly, or more frequently after any significant changes to your website's infrastructure, server configuration, application code, or CDN settings. Regular checks help ensure that your security headers remain correctly configured.

What are the most important security headers to check for?

The most critical security headers to prioritize are Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, and X-Content-Type-Options. These headers provide robust protection against common web attacks like XSS, clickjacking, and protocol downgrade attacks.

Can I check HTTP headers for an internal server?

You can check HTTP headers for an internal server if it's accessible from the network where you're running your check. If the server is not publicly exposed, you'll need to use command-line tools (like curl or wget) from within your internal network or a VPN connection to access it. Online tools like Secably's Analyzer can only reach publicly accessible websites.