Bug: `Sec-Fetch-User` is incorrectly added for non-user-activated requests, contrary to spec

[PurpleTape]

Hello!

I've identified a critical deviation from real browser behavior regarding how the Sec-Fetch-User header is generated. This discrepancy can signal to sophisticated bot detection systems that a request is automated.

The Problem: Incorrect Sec-Fetch-User Generation

The core of the issue is that impit unconditionally adds the Sec-Fetch-User: ?1 header to navigation-style requests. However, according to web standards, this header has a very specific meaning and should be omitted in most cases.

As stated in the MDN documentation, which reflects the Fetch standard:

The value will always be ?1. When a request is triggered by something other than a user activation, the spec requires browsers to omit the header completely.

— MDN Web Docs on Sec-Fetch-User

This means the header should only be present for navigations directly initiated by a user, such as clicking a link or typing a URL in the address bar. For all other requests, including loading subresources like iframes, images, scripts, or stylesheets, this header must be absent.

How to Reproduce

The issue can be easily observed by simulating a request for an iframe, which is not a direct user activation.

import { Impit } from 'impit';

const impit = new Impit({ browser: 'chrome' });

const response = await impit.fetch('https://httpbin.org/headers', {
    headers: {
        // Headers indicating a cross-site iframe navigation
        "Sec-Fetch-Dest": "iframe",
        "Sec-Fetch-Mode": "navigate",
        "Sec-Fetch-Site": "cross-site",
        "Referer": "https://an-example-site.com/",
    },
});

const data = await response.json();
console.log('Sec-Fetch-User:', data.headers['Sec-Fetch-User']); 

Actual Result

The Sec-Fetch-User header is present with the value ?1.

{
  "headers": {
    "Sec-Fetch-Dest": "iframe",
    "Sec-Fetch-User": "?1",  // <-- This is incorrect and violates the spec
    "..."
  }
}

Expected Result

The Sec-Fetch-User header should be completely absent from the request.

Scope of the Issue: A Comprehensive Rule

The problem is not limited to iframe. It applies to any request that is not a user-activated, top-level navigation. The Sec-Fetch-Dest header provides the necessary context to make the correct decision.

Here is a clear rule based on browser behavior:

• Sec-Fetch-User: ?1 SHOULD be sent only when Sec-Fetch-Dest is document, frame, or fencedframe, as these represent top-level document navigations that are typically user-initiated.

• Sec-Fetch-User SHOULD BE OMITTED for all other destinations. This includes, but is not limited to:

  • Embedded content: iframe, embed, object
  • Subresources: script, style, image, font, video, audio, track
  • Workers & Worklets: worker, sharedworker, serviceworker, audioworklet
  • API calls: empty (for fetch())
  • Other: manifest, report, xslt, etc.

By default, impit adds the header for many of these, creating an easily detectable fingerprinting flaw.

Why This Is a Critical Issue

1. Violation of Web Standards: The current behavior directly contradicts the Fetch specification, making the generated requests non-compliant.
2. Bot Detection: Advanced WAFs and bot detection systems (Cloudflare, Akamai, etc.) analyze the logical consistency of Fetch Metadata. A request for an image (Sec-Fetch-Dest: image) with a Sec-Fetch-User: ?1 header is an impossible combination for a real browser and a strong, definitive signal of automation.
3. Inability to Correct: This behavior cannot be fixed by the user. Setting "Sec-Fetch-User": undefined causes a crash, and setting it to another value is still incorrect. The library must handle the omission of the header correctly.

Proposed Solution

The library's internal header generation logic should be updated to respect the context provided by Sec-Fetch-Dest.

Suggested Logic:

Before sending a request, the logic for adding default headers should be as follows:

1. Check the user-provided Sec-Fetch-Dest header (or the one inferred by impit).
2. Only if Sec-Fetch-Dest is one of document, frame, or fencedframe, should the library add Sec-Fetch-User: ?1 (if it wasn't already provided by the user).
3. For all other values of Sec-Fetch-Dest, the Sec-Fetch-User header must not be added.

This change would align impit's behavior with web standards, drastically improving its stealth and the authenticity of the browser fingerprints it generates.

Thank you for your time and for maintaining this valuable project.

[PurpleTape]

Deeper Analysis: The Missing User Activation Context

The core realization is that the presence of Sec-Fetch-User is not solely determined by Sec-Fetch-Dest. It depends critically on whether the request was triggered by a direct user activation (like a click).

My initial issue correctly identified that for destinations like image or script, Sec-Fetch-User should be omitted. However, I incorrectly assumed that for Sec-Fetch-Dest: document, the Sec-Fetch-User: ?1 header should always be present. This is not true.

Here are critical scenarios where Sec-Fetch-Dest is a navigation target, but a real browser correctly omits the Sec-Fetch-User header:

1. HTTP Redirects: When a user clicks a link, the first request has Sec-Fetch-User: ?1. If the server responds with a 3xx redirect, the browser's automatic follow-up request still has Sec-Fetch-Dest: document, but it will not have the Sec-Fetch-User header, as it was initiated by the server, not the user.

2. JavaScript-Initiated Navigation: A navigation triggered by window.location.href inside a setTimeout will have Sec-Fetch-Dest: document but no Sec-Fetch-User header, because the user activation has expired.

This reveals that impit cannot infer the correct behavior from the provided headers alone. To address this, I'd like to propose potential solution.

---

Proposal: A "Magic Value" to Omit Header

As an alternative that avoids changing the API, impit could treat a specific value for Sec-Fetch-User as a special signal to omit the header entirely. The value '?0' is a good candidate.

New Logic:

1. If the user provides Sec-Fetch-User: '?0', the library removes the header from the final request.
2. If the user provides no Sec-Fetch-User header, the library uses its default logic.
3. If the user provides any other value (e.g., '?1'), it is sent as is.

Example Usage:

// Simulate a redirect by using the "magic value" to omit the header
await impit.fetch(redirectedUrl, {
    headers: { 
        "Sec-Fetch-Dest": "document",
        "Sec-Fetch-User": "?0" 
    }
});
// Result: The Sec-Fetch-User header is correctly OMITTED.

Trade-offs:

• Pro: No breaking API changes. Provides the necessary control.
• Con: Less discoverable than an explicit flag. The default behavior remains suboptimal.