# upgrade-insecure-requests (/en/docs/web-security/policies/content-security-policy/directives/upgrade-insecure-requests)



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)](/en/docs/web-security/security-headers/strict-transport-security). 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:

```http
Content-Security-Policy: upgrade-insecure-requests
```

## Fallback chain [#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 [#values]

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

## Examples [#examples]

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

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

## Security notes [#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 [#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](/tools/csp-evaluator).

## Recommendation [#recommendation]

```http
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 [#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](/en/docs/web-security/reporting-api/reports/csp-violation) without breaking anything.

## Browser support [#browser-support]

Widely supported across Chromium, Firefox, and Safari.

## FAQ [#faq]

### Does upgrade-insecure-requests replace HSTS? [#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](/en/blog/hsts-vs-upgrade-insecure-requests).

### What does upgrade-insecure-requests do? [#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.

## See also [#see-also]

* [block-all-mixed-content directive](/en/docs/web-security/policies/content-security-policy/directives/block-all-mixed-content)
* [Content-Security-Policy header with Reporting-Endpoints](/en/docs/web-security/reporting-api/headers/reporting-endpoints)
* [CSP keywords and values](/en/docs/web-security/policies/content-security-policy/values/csp-keywords)

## Sources [#sources]

* [MDN, CSP upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/upgrade-insecure-requests)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [W3C, Upgrade Insecure Requests](https://www.w3.org/TR/upgrade-insecure-requests/)
* [OWASP, Content Security Policy cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)