Security headers are instructions a website sends to a visitor’s browser. They help the browser make safer decisions about HTTPS, scripts, embedded pages, content types, shared information, and access to features such as the camera or microphone.
Most visitors never see these headers, but the browser reads them with every response. Good headers can reduce common web risks and limit the damage caused by certain mistakes. They do not repair vulnerable code, remove malware, update WordPress plugins, or replace strong authentication.
What do the main security headers do?
Each header answers a different browser-security question. The best set depends on what the website does, but the following headers are useful starting points for most public websites and web applications.
| Header | Plain-language purpose | Example value or decision |
|---|---|---|
| Strict-Transport-Security | Tells a browser to return through HTTPS instead of trying an unencrypted HTTP connection. | max-age=31536000 asks the browser to remember HTTPS for one year. Add subdomains only after confirming they all support HTTPS. |
| Content-Security-Policy | Limits where scripts, styles, images, frames, and other page resources may come from. This can reduce the impact of injected content. | A policy might allow the site’s own files while blocking unknown scripts. It should be designed and tested for that website. |
| X-Content-Type-Options | Tells the browser to respect the file type declared by the server instead of guessing what a file contains. | nosniff is the expected value. The server must still send correct content types. |
| Referrer-Policy | Controls how much of the current page address is shared when a visitor follows a link or loads another resource. | strict-origin-when-cross-origin keeps useful same-site detail while limiting what is shared with other sites. |
| Permissions-Policy | Controls whether the page and its embedded frames may use selected browser features. | A site that never uses the camera, microphone, or location can explicitly disable those features. |
| Frame protection | Controls whether another website may place the page inside a frame. This helps reduce deceptive clickjacking interfaces. | Use CSP frame-ancestors for modern control. Older sites may also use X-Frame-Options. |
| Cross-Origin-Resource-Policy | Helps control whether other websites may load certain resources from your site. | Use it only after checking how images, downloads, and integrations are legitimately shared. |
You may also encounter X-XSS-Protection in older checklists. Modern guidance does not rely on it because the browser feature it controlled is obsolete. A well-designed Content Security Policy and safe application code are more useful protections.
How to test security headers
Testing is safe because you are reading information the website already returns to a browser. Start with the homepage, then check login pages, account areas, forms, and other important routes. A website can send different headers on different pages.
1. Use the browser’s developer tools
Open Developer Tools, select the Network panel, and reload the page. Choose the main document request, then look for Response Headers. This shows the exact names and values the browser received. Search for headers such as content-security-policy, strict-transport-security, and x-content-type-options.
2. Check the response with curl
If you are comfortable with a terminal, curl provides a quick text view. The first command checks one response. The second follows redirects so you can see the final destination.
curl -sS -D - -o /dev/null https://example.com/
# Follow redirects to the final page
curl -sS -L -D - -o /dev/null https://example.com/3. Use MDN HTTP Observatory
MDN HTTP Observatory scans a public website and explains which HTTP security practices it detected. The score is useful for discovery, but it covers only part of website security. An A+ result does not check passwords, application permissions, plugin vulnerabilities, SQL injection, or every other risk.
How to understand the results
Do not stop at present or missing. Read the value and ask whether it provides meaningful protection. A header can be present but too permissive, incomplete, or unsuitable for the website.
- For HSTS, confirm the website is fully available through HTTPS before using a long duration.
- For CSP, look for broad sources, wildcards, and unsafe allowances that weaken the policy.
- For MIME protection, confirm
X-Content-Type-Optionsis set tonosniff. - For referrer policy, check whether full page addresses could expose private paths or query information.
- For permissions policy, disable features the website does not need.
- For frame protection, decide whether trusted external sites genuinely need to embed the page.
A header score tells you what the browser received. A useful review explains whether those values fit the website and the people using it.
J77Cyber review principle
How to improve headers safely
Begin with controls that are unlikely to change how the site works. Correct content types and X-Content-Type-Options: nosniff are sensible early steps. Choose a referrer policy that matches the site’s privacy and analytics needs. Disable unused browser features deliberately.
HSTS needs more care because browsers remember it. Confirm HTTPS first, begin with a shorter duration if necessary, and add subdomains only when every included hostname is ready. Content Security Policy also deserves a staged rollout. Use report-only mode, exercise the website, resolve legitimate violations, and enforce the tested policy.
Retest the homepage and important user journeys after every change. The goal is not to collect the largest number of headers. It is to give browsers clear instructions that match how the website actually works.