Missing Core Security Headers: What They Are and How to Add Them

What these headers do

A browser makes a lot of safe-by-default assumptions about a page, and a handful of response headers let you tighten those assumptions. BadgerScan flagged this because, from the outside view, several of these headers are simply absent, so the browser falls back to its more permissive defaults.

The three core ones are small and independent. X-Frame-Options controls whether other sites are allowed to load your pages inside an iframe, which is what blocks clickjacking (MDN, X-Frame-Options). X-Content-Type-Options: nosniff tells the browser to trust the content type you declared instead of guessing, which stops a file being reinterpreted as something executable (MDN, X-Content-Type-Options). Referrer-Policy controls how much of your URL is sent to other sites when a visitor clicks a link, so private paths and query strings do not leak.

Why it is worth fixing

These are hardening headers, not emergency fixes. Nothing on your site is broken today and their absence is not a sign of compromise. Each one just removes a specific browser-side risk: clickjacking of your login or checkout pages, MIME-type confusion attacks, and referrer leakage of URLs you would rather keep private.

The reason they are worth doing is the effort-to-benefit ratio. Unlike a Content-Security-Policy, these headers are static values that almost never break a normal site, so you can add all three in one change and be done. It is some of the cheapest security hardening available (OWASP, Secure Headers Project).

How to add them, step by step

Set these once at the layer that already sends your response headers, so every page gets them. That is usually your web server (Nginx, Apache), your CDN or host (Cloudflare, Netlify), or your application framework. Add the following three headers:

• X-Frame-Options: SAMEORIGIN — allows your own site to frame its pages but blocks other sites from doing so. Use DENY if you never embed your own pages in a frame.
• X-Content-Type-Options: nosniff — a single fixed value, safe on essentially every site. It stops the browser from second-guessing declared content types.
• Referrer-Policy: strict-origin-when-cross-origin — sends the full URL within your own site but only the origin to other sites, and nothing when downgrading from HTTPS to HTTP. This is the common, sensible default.
• Apply it site-wide, not per page. Add the headers at the server, CDN, or framework level so new pages inherit them automatically.
• Rescan to confirm. Run the free BadgerScan scan again and check that the headers now show as present in the outside view.

The one thing to watch

The only header here that can affect how a site works is X-Frame-Options. If you legitimately embed your own pages in an iframe (a booking widget, a help centre, a partner integration), DENY will break that embed. Use SAMEORIGIN if the framing is your own site, or move to a Content-Security-Policy frame-ancestors directive if you need to allow specific partner origins.

X-Content-Type-Options: nosniff and Referrer-Policy are safe to add on virtually any site with no visible change. If you want the stronger, more flexible framing control, see our Content-Security-Policy guide.