How to Check Security Headers of a Website
Learn how to check security headers of a website using browser developer tools and terminal commands to defend against clickjacking, XSS, and MIME sniffing.
Prerequisites and Expected Outcomes
Check headers on multiple distinct URLs across your domain, including the homepage, an authenticated portal, a static asset, and an intentional 404 error page. Web servers frequently apply different configuration blocks to dynamic paths and static files.
To evaluate how well your site tells web browsers to defend users, you must know how to check security headers of a website. When you finish this tutorial, you will have a complete inventory of the HTTP response headers your server delivers to visitors. You will know which defensive directives are currently active, which critical headers are missing, and how to verify that your web server enforces modern browser protections against common web attacks.
Before you begin this inspection, you need very little technical tooling. You will need a modern web browser such as Google Chrome, Mozilla Firefox, or Microsoft Edge installed on your computer. If you prefer automated or command-line workflows, you will also need access to a terminal environment that has curl installed. You do not need administrative access to the web server simply to inspect the headers, though server or content delivery network credentials will be necessary later if you need to add or modify directives. You can also compare your manual findings with our online Security Header Analyzer to spot missing controls quickly.
Inspect HTTP Headers Using Browser Developer Tools
Every modern desktop browser includes built-in developer tools that reveal exactly what headers the server sends with each response. To inspect your headers, open your web browser and navigate to the webpage you want to check. Open the developer tools panel by pressing F12, or press Control, Shift, and I on Windows and Linux, or Command, Option, and I on macOS. You can also right-click anywhere on the webpage and select the Inspect option from the context menu.
Once the developer panel opens, select the Network tab located along the top navigation bar. Refresh the browser page using Control and R or Command and R while keeping the panel open. The Network tab will populate with a list of all network requests executed to render the page. Scroll to the very top of the list and click on the primary document request, which shares the name of your domain or URL path. In the side panel that appears, ensure the Headers tab is selected, scroll down to the Response Headers section, and inspect each header name and value returned by the server.
Query Response Headers with the Command Line
Browser developer tools are visual, but command-line utilities provide a fast, scriptable method to check headers without rendering JavaScript or downloading page assets. The curl utility allows you to send an HTTP request and print only the server response headers directly to your terminal. This approach is helpful for system administrators who want to test web server configuration changes immediately without browser caching interference.
Open your terminal and run a curl request using the head flag and the silent flag. Passing the head flag instructs curl to issue an HTTP HEAD request or display response headers, while the location flag instructs it to follow any HTTP-to-HTTPS redirects. The verbose flag or the include flag can also show intermediate redirects if your site redirects HTTP traffic to HTTPS. Reviewing command output lets you confirm whether your security directives apply immediately on the initial redirect or only on the final destination page.
curl -I -s https://example.comEssential Security Headers and How to Interpret Them
The legacy X-XSS-Protection header has been superseded by modern CSP directives. The OWASP HTTP Headers Cheat Sheet advises setting X-XSS-Protection to 0 or omitting it entirely, as older browser XSS filters could introduce vulnerabilities in otherwise safe web applications.
Once you capture your server response headers, you must evaluate them against established security practices. Guidance published in the OWASP HTTP Headers Cheat Sheet explains that proper HTTP response headers help protect against cross-site scripting, clickjacking, and information disclosure. If a header is completely absent from your response, the browser applies its default behavior, which might leave your application exposed to avoidable risks.
The most critical security header is Content-Security-Policy. According to the MDN Content Security Policy documentation, CSP instructs the browser to place restrictions on what code is allowed to do and controls which JavaScript resources a document can execute. Strict-Transport-Security tells browsers to communicate with your site exclusively over HTTPS, preventing downgrade attacks. X-Content-Type-Options set to nosniff stops browsers from MIME-sniffing a response away from the declared content type. Referrer-Policy controls how much referrer information travels when visitors click external links. Permissions-Policy restricts access to browser hardware features like microphones and geolocation. For an in-depth breakdown of these controls, read our practical guide to HTTP security headers.
HTTP/2 200 OK
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000; includeSubDomains
content-security-policy: default-src 'self'; frame-ancestors 'none';
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), camera=(), microphone=()Header Audit Evaluation and Baseline Rules
You can evaluate the maturity of your server headers by comparing your captured output against standard security baselines. A robust response should strictly enforce encryption and restrict framing. Framing protection prevents attackers from embedding your pages inside hidden iframes on hostile domains, a technique commonly used to trick users into clicking buttons they did not intend to press. Aligning your application with the OWASP Top 10 requires minimizing insecure configurations like missing or misconfigured security headers.
Use this reference checklist to audit the headers returned by your web server. Check each item in your curl or browser output: Strict-Transport-Security should define a max-age value of at least 31536000 seconds. Content-Security-Policy should define fallback sources using default-src and restrict framing using frame-ancestors. X-Content-Type-Options must equal nosniff. Referrer-Policy should specify strict-origin-when-cross-origin or no-referrer. Finally, remove identifying application metadata such as X-Powered-By or detailed Server banners to avoid advertising underlying software versions to external observers. To run broader automated checks on your public domain, consult our Website Security Check.
Troubleshooting Missing or Broken Headers
If your testing shows that expected headers are missing or malformed, the issue typically stems from where the headers are injected. In modern web architectures, headers can be applied by a content delivery network, an edge reverse proxy like Nginx or Apache, a web application firewall, or the application framework itself. If you configured headers in your reverse proxy but do not see them in curl, verify whether your CDN or caching layer strips or overwrites origin response headers before delivering them to users.
Another common failure mode occurs when headers are applied only to successful responses. When an application returns an HTTP 301 redirect or an HTTP 500 error, many default server configurations bypass custom header directives. Ensure your server configuration directives apply globally across all response status codes. For administrators managing content management systems, verify that security plugins or caching layers do not conflict, and reference our WordPress security hardening checklist for configuration patterns that preserve headers consistently.
Step-by-Step Checklist
- 1Open your web browser and navigate to the target site
Launch your desktop web browser and enter the full HTTPS URL of the website you want to test in the address bar.
- 2Access the browser developer tools interface
Press F12 or right-click anywhere on the webpage and select Inspect to open the developer tools panel.
- 3Select the Network tab and reload the page
Click on the Network tab in the developer pane, then reload the page using Control and R or Command and R to record network activity.
- 4Inspect the initial document request
Scroll to the top of the request table and click the first entry matching your domain name to display its detailed properties.
- 5Review the response headers block
Click the Headers sub-tab in the request details pane and scroll down to the Response Headers section to view all returned security directives.
- 6Verify directives with a terminal curl command
Open a terminal window and run curl with the head flag against your URL to verify that headers return consistently without browser caching.
Frequently Asked Questions
Can I check website security headers without technical tools?+
Yes. While browser developer tools and curl provide raw technical output directly from the server, you can also use dedicated web-based testing tools. Entering your URL into an automated security header scanner will fetch the HTTP response, identify which security headers are present, highlight missing directives, and provide straightforward recommendations.
Why do my security headers disappear when visiting subdomains?+
HTTP response headers must be explicitly configured for each server block or host header. Unless your reverse proxy or DNS routing rules apply header injection rules globally across all hosts, or your primary domain uses Strict-Transport-Security with the includeSubDomains directive, child domains will not automatically inherit parent domain security configurations.
What is the difference between X-Frame-Options and Content-Security-Policy?+
X-Frame-Options is an older header designed specifically to prevent clickjacking by blocking the page from rendering inside frames. Content-Security-Policy provides a modern, comprehensive security framework. The frame-ancestors directive in CSP obsoletes X-Frame-Options in modern browsers and allows granular control over which external domains can frame your site.
Will adding security headers break functionality on my website?+
Strict-Transport-Security and X-Content-Type-Options rarely cause issues if your site already runs valid HTTPS and serves correct MIME types. However, an overly strict Content-Security-Policy can block necessary third-party scripts, analytics, fonts, or inline styles. Deploy CSP directives using the Content-Security-Policy-Report-Only header first to test for issues before enforcing restrictions.