Every time a browser loads a page, the server sends the content alongside a set of response headers. Most headers are technical plumbing, but a small group of them, the security headers, are direct instructions that tell the browser what it is allowed to allow. They are one of the cheapest and most effective defences a site can have, and checking them takes seconds.
A site with no security headers is not broken, but it leaves the browser to make its own assumptions, which is exactly what several classes of attack rely on.
Content-Security-Policy (CSP): a whitelist that controls where scripts, styles, images, and connections may come from. A strict CSP is the strongest defence against cross-site scripting, because even if an attacker injects script, the browser refuses to execute it from an unapproved source.
Strict-Transport-Security (HSTS): forces the browser to use HTTPS for a set period of time. It kills downgrade and first-visit interception attacks.
X-Content-Type-Options: nosniff: stops the browser guessing a files type, which prevents innocently named uploads from being executed as scripts.
X-Frame-Options / frame-ancestors: controls who may embed the site in an iframe, which is the basis of clickjacking attacks.
Referrer-Policy: limits how much of the current URL leaks to other sites when you click a link.
Permissions-Policy: switches off browser features like camera, microphone, and geolocation for the page or specific origins.
Cross-Origin headers (COOP, COEP, CORP): newer headers that isolate the site from other origins, blocking side-channel leaks.
The Headers page on EDX is a playground for building a header set. You toggle each header on or off, adjust its value, and the tool previews the exact response-header block your server would send and scores the configuration as you work. Presets like Maximum Security and Balanced give you a sane starting point instead of a blank page.
The score is a teaching signal, not a grade of your site. It rises as you enable stronger, correctly valued headers and drops when something important is missing or set loosely. Experimenting is the point: switch off CSP and watch the score fall, then loosen it with unsafe-inline and see what the change costs you.
When you are happy with a configuration, copy the generated block and add it to your server. For Nginx and Apache equivalents, the Config Generator on EDX can build the surrounding server configuration with these headers included.
A CSP is a list of directives separated by semicolons. Each directive names a resource type and the sources it may load from. For example, script-src 'self' means scripts may only come from the sites own origin, and script-src 'self' https://cdn.example.com adds one trusted CDN. The value unsafe-inline weakens the policy considerably, since it allows inline scripts, so treat it as a sign of a rushed setup. The default-src directive is the fallback for anything not named specifically, so a policy built around a tight default-src is usually a deliberate, well-considered one.
Security headers stop whole categories of attack in one line each. XSS containment comes from CSP, clickjacking from frame-ancestors, downgrade attacks from HSTS. They are also a reliable signal of whether the people running a site actually thought about security. When you assess any web service, headers are the first thing worth checking, because they tell you what the browser will enforce on your behalf before a single attack happens.
The following tools are commonly associated with this topic for research, testing, and defense:
Build and score a header set interactively, available on the Headers page.
Generates server configuration blocks that set these headers correctly.
See the XSS, CSRF, and Clickjacking guides for the attacks these headers are built against.
This guide is for educational purposes only. Only test headers on sites you own or have permission to assess. Do not use this knowledge for malicious activities. Always follow the law and ethical guidelines.