Proposal: CSP control over interactive HTTP authentication for subresources

[nirmalk401]

Executive Summary

This proposal introduces an opt-in extension to Content Security Policy that allows embedding origins to declaratively suppress interactive HTTP authentication challenges triggered by subresource responses. It adds a document-level directive enabling user agents to treat authentication challenges as blocked resources instead of initiating interactive authentication. A complementary proposal has been submitted to WHATWG (Fetch) to provide per-request programmatic control via a new RequestInit option.

1. Problem Statement

When a subresource response includes a 401 (Unauthorized) or 407 (Proxy Authentication Required) status code along with a corresponding authentication challenge header (e.g., WWW-Authenticate), the user agent may initiate interactive authentication.

The embedding origin has no declarative 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.

Embedding-origin enforcement is required to ensure that privileged browser authentication UI is not triggered by arbitrary third-party resources.

3. Proposed Directive Shape

Directive Syntax Example

Content-Security-Policy: auth-challenge 'block'

If omitted, the default behavior remains equivalent to:

auth-challenge 'allow'

Directive Semantics

• 'allow' (default): Existing behavior is preserved.
• 'block': Interactive HTTP authentication MUST NOT be initiated for subresource responses that include authentication challenge headers.

Interaction with Existing CSP Behavior

This proposal extends CSP’s enforcement model. It does not modify source matching semantics, request modes, or HTTP authentication semantics. It governs only whether interactive authentication is permitted when processing subresource responses.

4. Normative Enforcement Behavior

When processing a subresource response, if the protected resource’s policy includes auth-challenge 'block' and the response includes a WWW-Authenticate or Proxy-Authenticate header, then:

1. The user agent MUST treat the request as blocked by CSP.
2. The user agent MUST NOT initiate interactive authentication.
3. The user agent MUST NOT retry the request with credentials.
4. The user agent MUST fire a securitypolicyviolation event.

This proposal applies only to subresource requests. It does not modify the behavior of navigation requests (i.e., 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

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 may 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 authentication 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 CSP response-processing behavior for subresources.

7. Demonstration

A short demonstration video illustrating the current behavior has been provided for reference. https://drive.google.com/file/d/1AtuehiB9jlgre5OUEETtsqvoUFLM76HP/view