[whatwg/fetch] Proposal: Request-level control to suppress interactive HTTP authentication prompts (Issue #1910)

nirmalk401 created an issue (whatwg/fetch#1910)

### What is the issue with the Fetch Standard?

### Executive Summary
This proposal introduces an opt-in extension to the Fetch Standard that allows embedding origins to suppress interactive HTTP authentication challenges triggered by subresource requests. It adds a request-level control enabling user agents to treat authentication challenges as network errors instead of initiating interactive authentication. A complementary proposal has been submitted to W3C WebAppSec for declarative control via CSP.

### 1. Problem Statement
When a subresource request receives a 401 (Unauthorized) or 407 (Proxy Authentication Required) response including a corresponding authentication challenge header, the user agent may initiate interactive authentication.

The embedding origin has no mechanism to suppress this behavior.

In user-generated content environments, this may result in unexpected authentication prompts appearing within a trusted origin’s browsing context.

### 2. Why RFC 8053 Is Insufficient
RFC 8053 relies on the challenged server to include `Authentication-Control: no-auth`. This does not provide embedding-origin control and cannot be relied upon in adversarial or negligent third-party scenarios.

### 3. Proposed API Shape 

**WebIDL block example**

```
enum AuthPromptMode { "allow", "deny" };

dictionary RequestInit {
  ...
  AuthPromptMode authPrompt = "allow";
};
```
When constructing a Request, set request.[[AuthPromptMode]] to init.authPrompt.

**JavaScript Integration example**
```
// Default behavior (interactive auth allowed)
fetch("https://example.com/image.png");

// Explicitly suppress interactive authentication
fetch("https://example.com/image.png", {
  authPrompt: "deny"
});
```
If omitted, the default value is "allow", preserving existing behavior.

**Interaction with credentials**

The existing credentials option governs whether credentials are included in the request. This proposal governs only whether interactive authentication is initiated in response to authentication challenges. It does not modify the semantics of the credentials option.

### 4. Normative Algorithm Change
During HTTP-network fetch, before initiating HTTP authentication steps, if request.[[AuthPromptMode]] is "deny" and the response includes a `WWW-Authenticate` or `Proxy-Authenticate` header, then:

  1. The user agent MUST NOT initiate interactive authentication.
  2. The user agent MUST NOT retry with credentials.
  3. The user agent MUST treat the request as a network error.  

This proposal applies only to non-navigation requests. It does not modify the behavior of requests whose `mode` is `"navigate"`.

### 5. Real-World Abuse 
User-Generated Content (UGC) Platforms — including online marketplaces, social networks, forums, CMS-driven sites, and messaging platforms — allow users to embed third-party content such as images, media, and iframes.

In these environments, attackers can deliberately embed externally hosted resources that return HTTP 401 responses with WWW-Authenticate headers. When rendered inside a trusted origin (e.g., a well-known marketplace domain), user agents display interactive authentication prompts.

This creates a phishing vector:
• Users see a credential prompt while browsing a trusted site.
• Users may mistakenly enter credentials, believing the prompt is legitimate.
• Most users cannot distinguish cross-origin auth prompts.
• The embedding platform has no control over whether such prompts appear.

### 6.  Compatibility and Interoperability Considerations
• Backward compatible (opt-in only).
• Default behavior unchanged.
• No modification to HTTP authentication semantics.
• No impact on navigation requests.
• Change is confined to authentication handling in HTTP-network fetch.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1910
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1910@github.com>

Received on Monday, 16 February 2026 13:36:36 UTC