WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 4 weeks ago

#51438 new enhancement

Use CSP directive upgrade-insecure-requests when using HTTPS

Reported by: flixos90 Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.7
Component: Security Keywords: needs-patch needs-unit-tests
Focuses: Cc:

Description

While looking at ways on how to streamline HTTPS support in WordPress core, one suggestion has been to include a `Content-Security-Policy` directive of `upgrade-insecure-requests` for sites using HTTPS. This directive would ensure that browsers automatically replace (old) insecure requests for inline content (e.g. images) to use HTTPS (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests).

This could be as simple as injecting <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> into wp_head for sites that use HTTPS (see wp_is_using_https() from #47577). Alternatively, since this is mostly beneficial for sites that may still ("accidentally") have insecure URLs in their content after migrating from HTTP to HTTPS, it might make sense to rely on wp_should_update_insecure_urls() from #51437 instead.

Change History (3)

#1 follow-up: @ayeshrajans
10 months ago

Given that multiple CSP headers/meta tags will only further restrict the effective policy, I think this will be a change that would not overwrite if there is a CSP header sent at the web server level.

#2 in reply to: ↑ 1 @westonruter
4 weeks ago

Replying to ayeshrajans:

Given that multiple CSP headers/meta tags will only further restrict the effective policy, I think this will be a change that would not overwrite if there is a CSP header sent at the web server level.

Yes, that seems to be the case:

The CSP mechanism allows multiple policies being specified for a resource, including via the Content-Security-Policy header, the Content-Security-Policy-Report-Only header and a <meta> element.

You can use the Content-Security-Policy header more than once […] Adding additional policies can only further restrict the capabilities of the protected resource […]

So since upgrade-insecure-requests is more secure then not having this header, it should be able to override anything that came before. Anything coming after would not be able to undo upgrading insecure requests, since that would loosen the restrictions.

#3 @westonruter
4 weeks ago

  • Milestone changed from Awaiting Review to 5.9
  • Version set to 5.7

I think we can add this early in 5.9.

@flixos90 Any reason why meta tag preferred over HTTP response header?

Note: See TracTickets for help on using tickets.