[wp-trac] [WordPress Trac] #47577: Streamline detecting and enabling HTTPS

[WordPress Trac]

#47577: Streamline detecting and enabling HTTPS
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion needs-unit-tests has-    |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:7 miinasikk]:
 > How would you handle the case where external images are not available
 via HTTPS? Or are you thinking that perhaps `upgrade-insecure-requests`
 could be optional? Or maybe require handling first and/or logging the
 issues that need fixing?

 Yeah, I'm not sure. I think ultimately the insecure external assets would
 just need to fail. It's something the site owner (or theme/plugin
 developer) would need to fix (or find a replacement).

 Without `upgrade-insecure-requests` browsers will still load insecure
 images. Other insecure subresources, scripts in particular, are blocked
 entirely. So it seems better to have this in place so that the upgrade is
 performed for the majority of subresources that ''should'' be available
 over HTTPS.

 It would be nice if `upgrade-insecure-requests` could be configured to
 only upgrade non-image subresources, leaving images to flag insecure
 content warnings, but that doesn't seem to be the case.

 So while `upgrade-insecure-requests` should be the default, it makes sense
 that a developer should be able to turn off that default behavior and
 instead opt to [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
 /Content-Security-Policy/upgrade-insecure-
 requests#Finding_insecure_requests find insecure requests] via:

 {{{
 Content-Security-Policy-Report-Only: default-src https:; report-uri
 /endpoint
 }}}

 This would require the support of a plugin like
 [https://wordpress.org/plugins/reporting-api/ Reporting API]. It's also
 not something that should be the default for all sites.

 The 80% solution here—for the majority of users who don't know how to
 debug things like this—seems to be just to `upgrade-insecure-requests`.
 This should be come less and less of a problem as more sites support
 HTTPS.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47577#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform