Bugzilla

I don't understand how comment 2 differs from what you originally described, or how it contradicts what I said in comment 1 (though perhaps not clearly enough). As I understand it, the problem you describe has two aspects:

1: the sandbox attribute does not block an HTTP Auth prompt, unlike the `alert()` family of prompts (controlled by the `allow-modals` sandbox attribute) and "popups" like `window.open()` (controlled by the `allow-popups` sandbox attribute and others).

2. HTTP Auth from a cross-origin frame could fool a user into giving away the credentials for the top-level site if they are not careful

Is there something else I missed?

#1 appears to be a choice (or oversight?) of the specification, and all browsers appear to allow it. This should be addressed with the specification so all browsers work compatibly. Otherwise, if only one browser starts enforcing this users will get mad at their "broken" browser and could switch. See https://github.com/whatwg/html/issues

#2 is a spoofing problem whether or not the frame is sandboxed. We're aware, and we've tried to reduce the problem. But many times we run into problems where we've broken some site with enough users that we've had to back off. See bug 647010 and bug 1704346, for instance. We tried to make the dialog a little less spoofy by adding a warning that this is not the top-most site in bug 1230462.

Mitigating factors that help protect users:
* HTTP Auth is not used by many sites. Even if you don't read the warning it will not look like the normal login for the site you're on
* password managers won't be fooled, so if you use a password manager you will hopefully look closer when it doesn't autofill like normal
* if the target site uses Web Authentication ("passkeys") that can't be spoofed in this way

I wish we'd gotten further in blocking more cases of this under bug 647010. It's very hard to measure usage of this on the web.

I don't understand how comment 2 differs from what you originally described, or how it contradicts what I said in comment 1 (though perhaps not clearly enough). As I understand it, the problem you describe has two aspects:

1. the sandbox attribute does not block an HTTP Auth prompt, unlike the `alert()` family of prompts (controlled by the `allow-modals` sandbox attribute) and "popups" like `window.open()` (controlled by the `allow-popups` sandbox attribute and others).

2. HTTP Auth from a cross-origin frame could fool a user into giving away the credentials for the top-level site if they are not careful

Is there something else I missed?

#1 appears to be a choice (or oversight?) of the specification, and all browsers appear to allow it. This should be addressed with the specification so all browsers work compatibly. Otherwise, if only one browser starts enforcing this users will get mad at their "broken" browser and could switch. See https://github.com/whatwg/html/issues

#2 is a spoofing problem whether or not the frame is sandboxed. We're aware, and we've tried to reduce the problem. But many times we run into problems where we've broken some site with enough users that we've had to back off. See bug 647010 and bug 1704346, for instance. We tried to make the dialog a little less spoofy by adding a warning that this is not the top-most site in bug 1230462.

Mitigating factors that help protect users:
* HTTP Auth is not used by many sites. Even if you don't read the warning it will not look like the normal login for the site you're on
* password managers won't be fooled, so if you use a password manager you will hopefully look closer when it doesn't autofill like normal
* if the target site uses Web Authentication ("passkeys") that can't be spoofed in this way

I wish we'd gotten further in blocking more cases of this under bug 647010. It's very hard to measure usage of this on the web.