upgrade-insecure-requests, rewrite HTTP URLs to HTTPS

The CSP upgrade-insecure-requests directive rewrites a page's insecure HTTP subresource and navigation URLs to HTTPS before they are fetched.

The upgrade-insecure-requests directive tells the browser to rewrite a page's insecure http:// URLs to https:// before fetching them. It is the standard way to migrate a site to HTTPS without hunting down every hardcoded HTTP reference, and it removes most mixed-content warnings in one line.

When the directive is present, the browser upgrades the scheme of subresource requests (images, scripts, stylesheets, fonts, frames) and same-origin navigation requests from http: to https: before they leave the browser. The request is never sent over plaintext. Use the directive as a transition tool for content that still references http:// URLs.

It does not upgrade cross-origin top-level navigations (a user clicking a link to another site's http:// page is left alone), and it is not a replacement for HTTP Strict Transport Security (HSTS). HSTS forces HTTPS for the whole origin at the connection layer and survives across requests; this directive only rewrites the URLs inside the current document.

Send it on any HTTPS site that still references http:// URLs:

Content-Security-Policy: upgrade-insecure-requests

Fallback chain

upgrade-insecure-requests has no fallback. default-src does not cover it, so the directive only applies when you list it explicitly.

Values

None. It is a flag directive: its presence enables the behavior, and it takes no value.

Examples

A common migration policy upgrades references and still reports what the policy blocks:

Content-Security-Policy:
    default-src 'self';
    upgrade-insecure-requests;
    report-to csp-endpoint

Security notes

It closes mixed-content gaps. An HTTPS page that loads a script or stylesheet over http:// exposes that resource to tampering on the network, and active mixed content can compromise the whole page. Upgrading those requests to HTTPS removes the plaintext leg and the warning.

Known bypasses and risks

The upgrade is silent: if a resource has no HTTPS version, the request fails after the upgrade rather than falling back to HTTP, so an asset that is genuinely HTTP-only stops loading. It does not protect cross-origin top-level navigations, and it does not stop an attacker who controls the first plaintext request before any policy is read, which is what HSTS addresses.

You can confirm a policy carries the directive with the CSP evaluator.

Recommendation

Content-Security-Policy: upgrade-insecure-requests

Send the directive on every HTTPS site, especially during an HTTP-to-HTTPS migration, per OWASP and MDN guidance. It does not replace HSTS: keep Strict-Transport-Security to pin the origin to HTTPS at the connection layer, and use this directive to clean up in-page http:// references.

Reporting

The upgrade rewrites requests rather than blocking them. To find pages that still reference insecure URLs, run a report-only policy such as Content-Security-Policy-Report-Only: default-src https:; report-to csp-endpoint alongside it; each insecure request then produces a csp-violation report without breaking anything.

Browser support

Widely supported across Chromium, Firefox, and Safari.

FAQ

Does upgrade-insecure-requests replace HSTS?

No. upgrade-insecure-requests only rewrites http:// URLs inside the current document to https://. HSTS forces HTTPS for the whole origin at the connection layer and survives across requests, and it stops the first plaintext request before any policy is read. Keep both. See HSTS vs upgrade-insecure-requests.

What does upgrade-insecure-requests do?

It tells the browser to rewrite a page's insecure http:// subresource and same-origin navigation URLs to https:// before they are fetched, so the request never goes over plaintext. It removes most mixed-content warnings in one line and is the standard way to migrate a site to HTTPS without editing every hardcoded reference.

upgrade-insecure-requests