Re: Same Origin Policy and HTTP Authentication


Changing how HTTP authentication works is explicitly out of scope for this WG, although you will likely find people willing to discuss it here.

Although there are a number of places that might be appropriate for this discussion, it might actually be most helpful for you to give this as feedback to the W3C CORS specification:

... as they're discussing what is effectively a policy mechanism for cross-site requests.

Kind regards,

On 06/12/2010, at 5:43 AM, Chirag Shah wrote:

> Hey httpbis,
> Cross Site HTTP Authentication seems is an obscure phishing vector
> thatís often overlooked across the web and sometimes difficult to
> workaround. When the WWW-Authenticate header is presented to a
> user-agent, it will prompt the user for a user name and password .
> This is a problem because when a webpage is loaded, any external
> resource requested by that page can request HTTP Authentication and
> trigger this dialog. At this point, it isn't entirely obvious that the
> user name/password is being sent to the external resource.
> One way to address this issue is by disallowing HTTP Authentication
> for external resources loaded by a webpage by following a variant of
> the same-origin-policy.
> Proposed change in user agent behavior:
> When the page is rendered, the following
> table outlines how external resources (requiring Authentication) could
> be treated.
>           -      Auth Failure - Different domain
>        -      Auth Success - Same domain
> ws://     -     Auth Failure Different protocol
>   -      Auth Failure - Different port
>     -      Auth Failure - Different host
> Does it make sense to update RFC 2617 to account for this issue?
> References:
> Cross Site HTTP Authentication:
> HTTP Authentication:
> The Web Origin Concept:
> Thank you,
> Chirag Shah -

Mark Nottingham

Received on Monday, 6 December 2010 23:54:08 UTC