[wp-trac] [WordPress Trac] #47577: Streamline detecting and enabling HTTPS
WordPress Trac
noreply at wordpress.org
Fri Aug 2 18:01:12 UTC 2019
#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
More information about the wp-trac
mailing list