Does upgrade-insecure-requests replace HSTS?

No. UIR rewrites subresources on this page. HSTS remembers HTTPS for the host. You want the HTML fixed either way.

Should brochure sites set UIR?

Yes if old content still has http://. It is not a roast finding if you omit it after the HTML is clean.

Does RoastMyOpsec require upgrade-insecure-requests?

No. It looks for mixed-content URLs in landing HTML and reads HSTS. Missing UIR is not scored as a vulnerability.

Safety

upgrade-insecure-requests vs HSTS for Mixed Content

April 8, 2026

upgrade-insecure-requests vs HSTS for mixed content is a page-level rewrite versus a host-level memory. Content-Security-Policy: upgrade-insecure-requests tells supporting browsers to try HTTPS for http:// subresources on that document. Strict-Transport-Security tells them to skip HTTP for later navigations to the host (and includeSubDomains if you mean it). Neither deletes the http:// URLs in your HTML. Neither replaces a real redirect from :80 to :443. RoastMyOpsec parses the landing HTML for mixed-content http:// script, style, and image URLs and reads HSTS on the response. It does not score missing upgrade-insecure-requests as a finding and does not perform a man-in-the-middle test.

The practical difference

UIR is CSP. It runs in the document that sent it. A third-party iframe with its own policy is not your UIR. HSTS is the host. After a trusted HTTPS response with a usable max-age, later visits to that host should not use cleartext — until max-age lapses or the user clears site data.

A first visit over HTTP still needs a redirect. UIR does not upgrade the document navigation itself the way HSTS preload can. See HSTS vs HTTPS redirect.

How to choose what to ship

Fix the HTML: https:// for every first-party asset. Add HSTS when every included subdomain is ready. Add upgrade-insecure-requests as a belt while old CMS fields still emit http://. Do not preload HSTS to paper over mixed content. Do not set UIR and keep shipping active mixed scripts as a plan.

Control	Scope	Fixes leftover http:// in HTML?	Takeaway
upgrade-insecure-requests	This document's subresources	Rewrites fetches; does not edit the CMS	Belt while you delete http://
HSTS	Host (and subdomains if flagged)	No — navigations and memory	After HTTPS is real
HTTPS redirect	This request	No	Still required for the first hop
Delete http:// URLs	Your templates and CMS	Yes	The actual fix

What the roast can prove

Mixed-content hits are findings. Missing UIR is not. HSTS present or absent is graded as a header, not as proof that subresources upgraded. Pair with certificate expiry vs HSTS if max-age is heroic and renewal is not.

Common mistakes

The first mistake is UIR without HSTS and calling the site 'HTTPS-only.'

The second mistake is HSTS includeSubDomains while a blog subdomain still serves HTTP assets.

The third mistake is treating UIR as a substitute for CSP script-src.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Does upgrade-insecure-requests replace HSTS?: No. UIR rewrites subresources on this page. HSTS remembers HTTPS for the host. You want the HTML fixed either way.
Should brochure sites set UIR?: Yes if old content still has http://. It is not a roast finding if you omit it after the HTML is clean.
Does RoastMyOpsec require upgrade-insecure-requests?: No. It looks for mixed-content URLs in landing HTML and reads HSTS. Missing UIR is not scored as a vulnerability.