Security Headers: a beginner's guide

HTTP security headers are short instructions a web server sends along with every page that tell the browser how to defend the visitor against entire categories of attack. They are invisible to the user, free to deploy, and in many cases turn on protections that have been part of every modern browser for over a decade — they just have to be opted into. Think of them as the seatbelts your car already has installed: they only protect anyone if you actually click them in. Most websites today still ship with one or two of the seven major security headers in place; the rest are simply missing.

You should care because **the missing security headers on a typical website map directly to a list of attacks that the browser is willing to block, but isn't being asked to**. Cross-site scripting attacks, clickjacking, content sniffing, mixed-content downgrades, referrer leakage to third parties, FLoC tracking opt-outs — for almost every well-known browser-side attack, there is a header that disables the attack with a single line of configuration. The cost of adding the headers is one engineering ticket. The cost of not adding them is a steady trickle of preventable security incidents.

The seven HTTP security headers every audit looks at:

• Content-Security-Policy (CSP) — the most powerful. Specifies which sources of scripts, styles, images, and frames the browser is allowed to load. Properly configured CSP makes most cross-site scripting attacks impossible.

• Strict-Transport-Security (HSTS) — tells the browser to only ever connect to this domain over HTTPS, even if the user types `http://`. Closes the protocol-downgrade attack window.

• X-Frame-Options — tells the browser whether the page can be embedded in an iframe. Prevents clickjacking.

• X-Content-Type-Options: nosniff — tells the browser to honor the declared MIME type of every resource and not to second-guess it. Closes a class of MIME-confusion attacks.

• Referrer-Policy — controls how much of the previous URL is sent in the `Referer` header when users click links to other sites. Privacy-relevant.

• Permissions-Policy (formerly Feature-Policy) — controls which browser features (camera, microphone, geolocation, etc.) the page is allowed to use.

• Cross-Origin-Opener-Policy / Embedder-Policy / Resource-Policy — newer headers that protect against side-channel attacks like Spectre.

Three questions a security-headers audit answers:

• Which of the free, browser-built-in defenses am I currently leaving turned off?

• Are any of the headers I do have configured incorrectly, in a way that makes them ineffective?

• After my recent CMS or framework update, did any of the headers quietly disappear?

The cost of missing security headers is leaving the browser's built-in defensive features unused. The fix is one configuration change at the web server, CDN, or framework level — and modern hosting platforms (Vercel, Cloudflare Pages, Netlify) make it a few lines of config. The most authoritative reference is Mozilla's HTTP security headers documentation on MDN.

In one sentence: Analyze HTTP (HyperText Transfer Protocol) security headers, score, and compliance

Performs comprehensive analysis of HTTP (HyperText Transfer Protocol) security headers as recommended by OWASP Secure Headers Project. Evaluates Content-Security-Policy (CSP (Content Security Policy)), Strict-Transport-Security (HSTS (HTTP Strict Transport Security)), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and Cross-Origin policies (COEP, COOP, CORP). Returns a weighted security grade (A–F) with actionable remediation guidance. Also flags information disclosure risks from Server and X-Powered-By headers.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Fetches the target URL (web address) (with configurable redirect following) and inspects all security-related HTTP (HyperText Transfer Protocol) response headers. Each header is scored against known good values: HSTS (HTTP Strict Transport Security) is checked for max-age ≥ 1 year, includeSubDomains, and preload; CSP (Content Security Policy) is validated for presence and baseline directives; X-Frame-Options is checked for DENY or SAMEORIGIN; X-Content-Type-Options must be nosniff; Referrer-Policy is evaluated against recommended values (no-referrer, strict-origin-when-cross-origin). The deprecated X-XSS-Protection header is detected and flagged — modern browsers have removed XSS Auditor support, and CSP is the recommended replacement. A composite grade is computed from all header scores.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Security Headers tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

HTTP (HyperText Transfer Protocol) security headers are your first line of defense against common web attacks including XSS, clickjacking, MIME-sniffing, and protocol downgrade attacks. OWASP, Mozilla Observatory, and compliance frameworks (PCI-DSS 4.0, SOC 2 (Service Organization Control 2), HIPAA) all recommend these headers. Regular auditing catches misconfigurations before attackers exploit them — 67% of websites are missing at least one critical security header according to recent surveys.

Picture this in real life. Imagine a security engineer. Here's the situation they're walking into: Before deployment, verify that all required security headers are properly configured across web applications. Compare results against OWASP Secure Headers Project recommendations. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Security Headers tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Security Headers tool is built for you:

• Is my website encrypted properly, or are visitors going to see a scary browser warning?

• Am I missing any of the security headers that modern browsers expect?

• Could a known weakness on my site quietly be costing me trust, traffic, or compliance?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Founders and freelancers running their own sites, agencies handing off projects to clients, security and compliance teams chasing audit findings, and developers hardening login pages. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and visitors get browser warnings, search engines lose trust in your site, and a single missed setting can become a public security incident. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the Security Headers tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a security engineer, a compliance officer, a security analyst, and a devops engineer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Application Security Audit

Imagine you're a security engineer. Before deployment, verify that all required security headers are properly configured across web applications. Compare results against OWASP Secure Headers Project recommendations.

Why it matters: Catch security header misconfigurations before they reach production.

Story 2: Compliance Verification

Imagine you're a compliance officer. Document security header configuration as evidence for PCI-DSS 4.0 Requirement 6.4, SOC 2 (Service Organization Control 2) CC6.1, or HIPAA Technical Safeguards audits.

Why it matters: Automate compliance evidence collection for security controls.

Story 3: Vendor Security Assessment

Imagine you're a security analyst. Evaluate the security posture of third-party vendors and SaaS providers by analyzing their web application security headers as part of vendor risk management.

Why it matters: Assess vendor security without requiring access to their infrastructure.

Story 4: CI/CD Security Gate

Imagine you're a devops engineer. Integrate security header checks into automated deployment workflows to automatically validate headers after each deployment.

Why it matters: Prevent security regressions with automated header validation.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Security Headers tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• After every site redesign or platform migration.

• Before a penetration test, security review, or vendor questionnaire.

• When your SSL certificate is about to expire and you want to confirm the renewal worked.

• On a recurring monthly schedule, so you catch new issues before attackers do.

If you can see yourself in even one of those bullets, the Security Headers tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Security Headers tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the Security Headers tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

You need to provide 2 pieces of information when you call this tool. The table below lays them out side by side, with a real example for each one so you can see exactly what to send.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with Security Headers. If you're already running this check, the related ones often answer the next question that comes up:

• HSTS Check — Check HSTS policy and preload status

• Security Score — Composite security score from 8 weighted factors

• SSL Certificates — Analyze active SSL/TLS certificate details

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check Security Headers and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

URL (web address) — The full address of a page, like https://example.com/about.

HTTP (HyperText Transfer Protocol) — The language web browsers and websites use to talk to each other.

CSP (Content Security Policy) — A list, sent in a page header, of where the page is allowed to load images, scripts, and other resources from. Stops a lot of common attacks.

HSTS (HTTP Strict Transport Security) — A header that tells browsers "always use HTTPS for this site, never plain HTTP, even if the user types it." Prevents downgrade attacks.

SOC 2 (Service Organization Control 2) — A widely used security audit. Proves to customers that you handle their data responsibly.