3

I have two questions regarding the CSP directive upgrade-insecure-requests which I couldn't answer myself by reading the specification.

  1. What happens to ressources which can't be upgraded to https (e.g. invalid certificate)? Will they be blocked?
  2. What kind of violations will be reported against the endpoint specified by report-uri in the policy? Just failed upgrades or also successful upgrades?
3
+50

What happens to ressources which can't be upgraded to https (e.g. invalid certificate)? Will they be blocked?

The request will be made over HTTPS. If the request fails, then it fails. To do otherwise would open the system up to downgrade attacks, making it effectively useless against a MITM attacker.

This behavior is specified in the Fetch Standard from the WHATWG (which is referenced in the upgrade-insecure-requests spec):

  1. Upgrade request to a potentially secure URL, if appropriate.

Since this step happens before any actual network requests are made, the rest of the process behaves exactly as if the request was originally made as HTTPS from the beginning.


What kind of violations will be reported against the endpoint specified by report-uri in the policy? Just failed upgrades or also successful upgrades?

No violations will be reported by a CSP directive using upgrade-insecure-requests. According to the spec:

Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header. Authors can determine whether or not upgraded resources' original URLs were insecure via Content-Security-Policy-Report-Only. For example, Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint. See §3.4 Reporting Upgrades for additional detail.

So if you want information on which requests are being upgraded using CSP, you must use a hard fail (not upgrade-insecure-requests) with the Report-Only header.

Section 3.4 further explains this in example 9:

Within the context of a protected resource which contains the insecure image <img src="http://example.com/image.png">, and delivers the following HTTP headers:

Content-Security-Policy: upgrade-insecure-requests; default-src https:
Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint

The user agent will fire off a request request that:

  1. Violates the policy being monitored, thereby delivering a violation report to /endpoint.
  2. Is upgraded from http://example.com/image.png to https://example.com/image.png.
  3. Does not violate the policy being enforced.

Note that point 3 here is key. Since the request is upgraded in step 2, the request does not "violate the policy being enforced". According to the CSP spec, only violations of the CSP policy are reported:

When one or more of a policy’s directives is violated, a violation report may be generated and sent out to a reporting endpoint associated with the policy.

  • Thank you for your answer and pointing me to Example 9! I understand that successful upgrades won't violate the Content-Security-Policy and therefore won't fire off violation reports. Can you elaborate on the case that Content-Security-Policy has set a report-uri and the upgrade fails? Then there will be a report, right? – HorstKevin Nov 13 '17 at 21:11
  • The upgrade can't fail, because the upgrade happens before anything even touches the network. (Again, see the Fetch Standard, step 2.3.) If the resulting network request fails, that's no different from if any other network request on your site failed. – Ajedi32 Nov 13 '17 at 21:31
  • @HorstKevin If you want to check whether a URL is failing to load because its host doesn't support HTTPS, you could always just use Content-Security-Policy-Report-Only, and have your server check the links out of band to make sure they load properly over HTTPS. – Ajedi32 Nov 13 '17 at 21:33
5

1. What happens if an upgrade fails?

Exactly the same thing that would happen if a non-upgraded HTTPS request failed. The spec talks about rewriting requests. Exactly how this is done is explained in section 4.1 of the spec, but the essence is that http:// is replaced with https://. That means that once the request is rewritten it is indistinguishable from a request that was HTTPS from the beginning.

To be honest I can't find any good section of the spec to quote where this is crystal clear. But example one and three quite directly show that this is the case.

2. What will be reported?

No successful upgrades, no failed upgrades, nothing. From section 3.1 of the spec:

Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via a Content-Security-Policy-Report-Only header.

  • Thank you for your answer! But, I think your answer to my second question isn't to the point. I can also specify a report-uri directive in a Content-Security-Policy (not Content-Security-Policy-Report-Only). – HorstKevin Nov 13 '17 at 21:06
  • 1
    @HorstKevin First part of the quoted sentence says it all. Monitoring has no effect. That applies for both headers. The second part does not limit the first. – Anders Nov 14 '17 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.