core(is-on-https): pass if http redirects to https#15907
core(is-on-https): pass if http redirects to https#15907
Conversation
core/audits/is-on-https.js
Outdated
| const devtoolsLogs = artifacts.devtoolsLogs[Audit.DEFAULT_PASS]; | ||
| const networkRecords = await NetworkRecords.request(devtoolsLogs, context); | ||
| const insecureURLs = networkRecords | ||
| .filter(record => !record.redirectDestination) |
There was a problem hiding this comment.
This should be limited to the initial document request chain and not allow any other resources that redirected.
There was a problem hiding this comment.
Also don't want to allow https -> http -> https redirects?
There was a problem hiding this comment.
This should be limited to the initial document request chain and not allow any other resources that redirected.
sgtm, but should we allow iframe documents as well or just the main document?
Also don't want to allow https -> http -> https redirects?
The impl in #13548 doesn't seem to care about intermediate redirects. Is there a strong reason for this?
There was a problem hiding this comment.
sgtm, but should we allow iframe documents as well or just the main document?
IMO the only leeway should be if you put in an http URL to test, so not including iframes, yeah. Like you can't control what URL a user starts with (can only redirect them), but you can control the URLs of any iframes the page loads.
Also don't want to allow https -> http -> https redirects?
The impl in #13548 doesn't seem to care about intermediate redirects. Is there a strong reason for this?
Yeah, not included there, and I added the question mark because I'm not sure if it's worth failing on. I was just trying to think through possible failure modes.
Seems bad? Starting secure but letting an intermediate response do any number of things that could be intercepted/altered. OTOH is there any increased risk vs starting with an insecure request? OTOOH, kind of ridiculous if that's the redirect chain for your site?
There was a problem hiding this comment.
Starting secure but letting an intermediate response do any number of things that could be intercepted/altered.
This has me leaning more towards #13548 and closing this PR haha. This sounds like a real security problem that we would want to flag in any situation. It's just a more severe problem if the site didn't at least redirect to https.
There was a problem hiding this comment.
Haha, well, up to you :)
Couldn't resist checking, and there are about 100k/0.4% of sites in a recent HTTP Archive crawl that did this (went at least https->http->https, ending on an https).
Interestingly ~99% of them end up on the same origin they started on by the end of things. A lot of them are of the form
https://example.comhttp://example.com/enhttps://example.com/en
so it does seem like a real error and something they can/should fix
|
Going back to reviving #13548 |
Halfway through updating #13548, I realized this audit already covers the passively checking http/https case. However, it will still flag insecure requests even if they redirect to a secure protocol.
This PR creates an exception for insecure main document redirects.