Skip to main content
Security Auditor — renders the audited page in a headless Chromium and reports every resource it loaded over plain http://, telling apart pages whose Content-Security-Policy carries upgrade-insecure-requests (browsers rewrite those requests to HTTPS) from pages that have no such safety net.

Protection

Keeps the padlock on your HTTPS pages and stops scripts, styles and frames from being blocked or tampered with on the network.

Standards

Follows the W3C Mixed Content (Level 2) specification that browsers implement when they block or upgrade insecure subresources.
Mixed content is a resource loaded over plain HTTP by a page served over HTTPS. Browsers block the most dangerous kinds (scripts, stylesheets, frames, XHR) outright, so the page breaks, and they either upgrade or block images, video and audio, dropping the padlock from the address bar. Anyone on the network between the visitor and your site can read or alter a plain HTTP request. This auditor loads the page the way a visitor does and lists every such resource.

​
How it works

  1. Render — launches a headless Chromium as 37AuditsBot and navigates to the audited URL, waiting up to 60 s for the load event and then up to 15 s more for the network to go idle (a page that keeps polling is judged on the requests seen by then). A blocked page ends the audit with 590; no response or an HTTP status of 400 or more ends it with 500; a browser failure that survives one relaunch ends it with 501.
  2. Collect — records every request the browser made while loading, plus the resolved src / href of every img, script, link, iframe, video, audio and source element left in the rendered DOM. A resource counts only when its URL starts with http:// (any letter case); the audited document and its redirect hops never count. Each URL is reported once, with the place it was first seen (request or dom).
  3. Upgrade directive — reads Content-Security-Policy from the final response the browser rendered (after redirects); when there is no header, from a <meta http-equiv="Content-Security-Policy"> tag. The page has the safety net when one of the directives is upgrade-insecure-requests.
  4. Rules — every insecure resource fails (400) when the directive is absent, or warns (300) when it is present. FAIL wins over WARNING; when nothing was loaded over plain HTTP the audit is SUCCESS (200) and names the number of requests observed.
  5. Specification pin — every run emits 37A-MixedContentAuditor-100 (INFORMATION), naming the W3C Mixed Content (Level 2) Candidate Recommendation Draft of 2023-02-23. It does not change the overall status.

​
What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 100 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​
Output documentation

Each 300 / 400 check carries resource, source (request when the browser fetched it, dom when only the rendered markup references it), hasUpgradeInsecureRequests and csp (the policy, truncated to 300 characters) in its data; the 200 check carries url, requestCount, hasUpgradeInsecureRequests and csp.

​
Risks and considerations

​
Why mixed content matters

  • Browsers block insecure scripts, stylesheets, frames and fetches on an HTTPS page, so a single http:// script tag can take down a feature for every visitor.
  • Images, video and audio over HTTP are upgraded by current browsers and blocked when the upgrade fails; older browsers load them and drop the padlock, which visitors read as “this site is not safe”.
  • A plain HTTP request can be read and rewritten on the network, so an insecure script is a remote code execution vector on your page.

​
upgrade-insecure-requests is a stopgap

  • The directive tells browsers to rewrite http:// requests to https:// before sending them. It hides the problem from visitors on current browsers, but the page source still points at insecure URLs, and the upgrade fails silently when the host serves no HTTPS. Fix the URLs and keep the directive as a safety net.
  • The auditor reads the directive from the response header first and from a <meta http-equiv> tag only when there is no header, like browsers combine them.

​
What changed in this version

  • http:// inside a query string (for example ?u=http://example.com) no longer counts: a resource is flagged only when its own URL starts with http://.
  • The audited document and its redirect hops are never flagged, even when the audited URL is itself plain HTTP.
  • The Content-Security-Policy header is read from the final response after redirects; before, it was only found when no redirect happened.
  • A page that answers HTTP 400 or more is an ERROR (500) instead of being audited as if it were the site.
  • A browser failure is an ERROR with its own code (501) instead of the raw Playwright message with no code.
  • Verdict severities are unchanged: an insecure resource still fails, and still warns when upgrade-insecure-requests is present.

​
What this auditor does not check

  • Only the audited URL is rendered; other pages of the site may load insecure resources.
  • Requests made after the 15 s network-idle cap, or after a user interaction, are not seen; the result message says so when the page never went idle.
  • A link element is reported whatever its rel, so an http:// canonical or alternate link shows up although browsers never fetch it.
  • Resources behind a consent banner or a login are only seen when the page loads them anyway.