How to Check Your Website for Missing Security Headers and Mixed Content

You check a website for missing security headers by requesting a page and reading the HTTP response headers the server sends back, then comparing them with a short list of protective headers that every modern site should return. Mixed content is checked separately, by scanning the page’s HTML for images, scripts, stylesheets or frames still loaded over plain http:// on a page served over HTTPS.

Both problems are invisible to most site owners. The page looks normal, the padlock may still appear, and nothing seems broken. Yet a missing header can leave visitors exposed to clickjacking, content sniffing or downgrade attacks, and mixed content can break a page’s layout or functionality outright. A website security checker runs both checks together and lists what is missing.

The headers that matter, and what each one prevents

Security headers are instructions your server sends to the browser alongside each page. They cost almost nothing to add and close off whole categories of attack.

Strict-Transport-Security (HSTS) : Tells the browser to use HTTPS for your domain for a set number of seconds, even if someone types or clicks an http:// link. It stops attackers on public Wi-Fi from intercepting that first insecure request. Browsers ignore it if it arrives over plain HTTP.

Content-Security-Policy (CSP): Lists which sources the browser may load scripts, styles, images, frames and other resources from. It is the strongest defence against cross-site scripting, and its frame-ancestors directive controls which sites may embed your pages.

X-Content-Type-Options: The single value nosniff stops browsers guessing a file’s type, so an uploaded file disguised as an image cannot be run as a script.

X-Frame-Options: The older way to prevent clickjacking, with values DENY or SAMEORIGIN. CSP’s frame-ancestors offers finer control, but sending both is still common for older browsers.

Referrer-Policy: Controls how much of the current URL is passed to other sites when visitors follow a link. strict-origin-when-cross-origin is a sensible balance: full URLs within your site, only the domain to others, and nothing when moving from HTTPS to HTTP.

Permissions-Policy: Switches off browser features your site does not need, such as the camera, microphone or geolocation, so injected or third-party code cannot request them.

How browsers handle mixed content

Mixed content means an HTTPS page pulling in resources over HTTP. Current browsers treat it in two ways. Images, audio and video loaded through a plain src attribute are automatically upgraded to HTTPS where possible, and blocked if the upgraded request fails. Almost everything else, including scripts, stylesheets, iframes, web fonts, and data fetched by JavaScript, is blocked outright. A blocked stylesheet can leave a page unstyled; a blocked script can break a checkout button or a contact form with no visible error message.

Mixed content usually comes from hard-coded URLs: an old theme file, a page-builder widget saved before the move to HTTPS, an embedded map or video, or image links stored in the database.

Worked example: a sample security check, line by line

The table below shows a sample result for the home page of a small US law firm. The site uses HTTPS and has a valid certificate, so the owner assumed it was secure.

Line 1. Without HSTS, a visitor who types the bare domain makes one unencrypted request before being redirected. That request can be intercepted. Add the header, starting with a short duration to test, then increase it.

Line 2. No CSP means any injected script would run without restriction. CSP takes care to configure, so begin in report-only mode to see what would be blocked before enforcing.

Lines 3 and 4. Both are present and correct. Many hosting platforms add these by default, which is why partial results like this are common.

Line 5. Modern browsers apply a reasonable default when this header is absent, but setting it explicitly makes the behaviour consistent and deliberate.

Line 6. A law firm’s site has no reason to access a visitor’s camera or location. Disabling those features costs nothing.

Line 7 is the most serious finding. An old live-chat widget loads its script over HTTP, so browsers block it and the chat button never appears. The firm had been losing enquiries without knowing why. Changing the URL to HTTPS, or removing the widget, fixes both the security issue and the lost leads.

Line 8. Four images in an old blog post use http:// links. Browsers will try to upgrade them, but the links should still be corrected in the database so they do not depend on that behaviour.

Line 9. Advertising the exact server version helps attackers match known vulnerabilities. Hide or trim the header where your host allows it.

A reasonable starting set for this site, added in the server or CDN configuration, could be:

Scan your own site: enter your website address in the free security headers and mixed content checker to see which headers your server returns, which are missing and which resources are still loading over HTTP.

Rolling out fixes without breaking the site

Security headers can break things if applied carelessly, so introduce them in a sensible order.

• Start with the safe ones. X-Content-Type-Options, Referrer-Policy and Permissions-Policy rarely cause problems.

• Add HSTS gradually. Begin with a max-age of a day or a week, check every subdomain works over HTTPS, then raise it to a year (31,536,000 seconds). Only add includeSubDomains and preload once you are sure; preload list removal is slow.

• Build CSP from reports. Run in report-only mode, list the third-party services you actually use (analytics, payments, fonts, video) and allow only those.

• Fix mixed content at the source. Update URLs in templates and run a database search-and-replace from http://yourdomain to https://yourdomain, after taking a backup.

Headers protect a working HTTPS connection; they cannot replace one. Confirm your certificate and chain are sound with an SSL checker, and use a redirect checker to make sure every HTTP address moves to HTTPS in a single permanent step.

Frequently asked questions

Which security headers should every website have?

A strong baseline is Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options set to nosniff, Referrer-Policy and Permissions-Policy, with frame protection through CSP frame-ancestors or X-Frame-Options. The exact CSP depends on the services your site uses, so it needs tailoring rather than copying from another site.

How do I see a website’s security headers myself?

Open your browser’s developer tools, go to the Network tab, reload the page and select the first document request. The response headers are listed there. An online checker gives the same information in a clearer format, rates each header and adds a scan for mixed content.

Why does my site show a padlock warning even with a valid certificate?

That usually means mixed content: the page itself is encrypted, but some resources are requested over plain HTTP. Find each insecure URL, change it to HTTPS or host the file yourself, and remove anything from a third party that no longer supports secure connections.

Can security headers slow down my website?

No meaningfully. Headers add a few hundred bytes to each response. HSTS can make repeat visits slightly faster because the browser skips the HTTP-to-HTTPS redirect. The only performance risk is a CSP that accidentally blocks a resource your page needs, which report-only testing will reveal.

Security headers and clean HTTPS resources are quick, low-cost protections that most small business sites still lack. Check where yours stand, fix the gaps in order of risk and recheck after every new plugin or embedded service with the TechBullion website security scanner.