Skip to content
Header Hawk

upgrade-insecure-requests

upgrade-insecure-requests tells the browser to treat every insecure URL in the document as if it had been written https://. It takes no value.

It is the pragmatic answer to a large legacy codebase full of http:// URLs you cannot all find: the upgrade happens before the request, so there is no mixed-content warning and no round trip.

Syntax

Section titled “Syntax”
Content-Security-Policy: upgrade-insecure-requests;

What it controls

Section titled “What it controls”
  • Non-navigational subresource requests - images, scripts, styles, fonts, frames - both first-party and third-party.

What it does not control

Section titled “What it does not control”
  • Navigational requests to third-party origins. A link to http://elsewhere.example/ is left alone, because upgrading it breaks too much.
  • Availability. There is no fallback: if the resource is not served over HTTPS, the upgraded request simply fails.

Fallback

Section titled “Fallback”

upgrade-insecure-requests has no fallback and takes no value. It is either present or it is not.

Section titled “Recommended value”
Content-Security-Policy: upgrade-insecure-requests
  • Set it on any HTTPS site. There is no downside for a site whose resources are all available over HTTPS, and it removes a whole class of mixed-content failure.
  • Pair it with Strict-Transport-Security. upgrade-insecure-requests does nothing for the top-level navigation that got the user to your page; HSTS is what handles that.
  • Do not set block-all-mixed-content alongside it. upgrade-insecure-requests is evaluated first, and when it is present the older directive does nothing.

Examples

Section titled “Examples”

Allowed

Section titled “Allowed”

Requested over HTTPS despite the markup:

<img src="http://cdn.example.com/logo.png" alt="" />

Blocked

Section titled “Blocked”

Left as written - navigational, and third-party:

<a href="http://partner.example/">Partner</a>

Browser support

Section titled “Browser support”
  • Widely available across browsers since April 2018.
  • Works in a <meta http-equiv> policy as well as a header.

In a HeaderHawk report

Section titled “In a HeaderHawk report”
  • The directive upgrades requests rather than refusing them, so there is nothing to report. It produces no violations in HeaderHawk.
  • If an upgraded request fails because the host has no HTTPS, that is a network error, not a CSP violation - it will not appear in your reports. Watch for it in the browser console or in your own error tracking instead.
Section titled “Related directives”

Getting reports for this directive

Section titled “Getting reports for this directive”

Point your policy’s report-uri at your site’s HeaderHawk endpoint and the violations above arrive in the dashboard, grouped as described. The Quick Start sets that up in five minutes, and the integration guides cover the header syntax for each platform.