How Unauthenticated HTTPS Fetch Calls Happen in JavaScript and How to Fix Them

The Vulnerability in Context

The script.js file in this accessibility widget library contains a feature that summarizes text content by POSTing it to an external service at https://a11y-widget.jerit.in/summarize. On the surface, using HTTPS looks safe. But at line 1152, the fetch() call was missing two critical security properties — and that gap opened the door to man-in-the-middle (MITM) attacks and unintended credential exposure for every user of this library downstream.

Because this is a distributed Node.js/browser library, the vulnerability doesn't just affect one application. It affects every project that installs and uses this widget, multiplying the real-world blast radius significantly.

The Vulnerability Explained

What the Vulnerable Code Looked Like

Here's the fetch call as it existed before the fix (around line 1152 of script.js):

formData.append('data', text)
const response = await fetch('https://a11y-widget.jerit.in/summarize', {
  method: 'POST',
  body: formData
});

At first glance, this looks fine — it's HTTPS, it's a POST, it passes formData. But notice what's absent: there is no mode property and no credentials property in the fetch options.

Why Omitting These Properties Is Dangerous

Missing mode:
When mode is not explicitly set, the browser defaults to 'cors' for cross-origin requests — but this default behavior can be inconsistent across environments and does not communicate developer intent. More critically, in some configurations (e.g., with service workers, certain polyfills, or older browser quirks), the absence of an explicit mode can allow the request to fall back to a less restrictive mode. Explicitly declaring mode: 'cors' ensures the browser always enforces the Cross-Origin Resource Sharing protocol, and will refuse to complete the request if the server doesn't return the correct CORS headers.

Missing credentials: 'omit':
Without this property, the browser defaults to credentials: 'same-origin' for most fetch calls, but this default is not universally safe. In certain browser contexts, cookies, HTTP authentication headers, or TLS client certificates associated with the user's session could be forwarded to the external domain a11y-widget.jerit.in. For a third-party widget making calls to an external summarization API, this is a serious overshare.

The Attack Scenario

Consider a user on a public Wi-Fi network — a coffee shop, airport, or hotel — who has the widget embedded in a site they're visiting. An attacker on the same network performs ARP spoofing or DNS hijacking to redirect traffic destined for a11y-widget.jerit.in to their own server.

Because the original fetch call lacked credentials: 'omit', the browser might forward session cookies or auth headers to the attacker's server. The attacker can then:

1. Capture any forwarded credentials associated with the user's browsing session.
2. Return a malicious response from the spoofed summarization endpoint — potentially injecting content into the widget's output, which could escalate to XSS if the response is rendered without sanitization.
3. Log all text content being summarized (which could include sensitive document content pasted by the user).

The fact that this is a library makes it worse: the attacker only needs to compromise the DNS or network path for a11y-widget.jerit.in once, and it affects every site using the widget simultaneously.

The Fix

What Changed

The fix is surgical and precise — two lines added to the fetch options in script.js:

Before (vulnerable):

formData.append('data', text)
const response = await fetch('https://a11y-widget.jerit.in/summarize', {
  method: 'POST',
  body: formData
});

After (fixed):

formData.append('data', text)
const response = await fetch('https://a11y-widget.jerit.in/summarize', {
  method: 'POST',
  mode: 'cors',
  credentials: 'omit',
  body: formData
});

Why Each Change Matters

mode: 'cors'
This explicitly tells the browser: "This is a cross-origin request, and it must comply with CORS protocol." If the server at a11y-widget.jerit.in does not return appropriate Access-Control-Allow-Origin headers, the browser will block the response entirely. This is the correct, defensive posture for any fetch to a third-party domain. It also makes developer intent explicit and auditable — future maintainers won't have to guess whether CORS was considered.

credentials: 'omit'
This is the more impactful of the two changes from a credential-safety perspective. It explicitly instructs the browser: do not send cookies, HTTP auth headers, or TLS client certificates with this request. Since the summarization endpoint is a third-party service that has no legitimate need for the user's session credentials, omitting them entirely eliminates the credential leakage attack surface. Even if an attacker successfully spoofs the endpoint, they receive no credentials.

Together, these two properties close the MITM credential-leakage vector and harden the widget's network behavior to the principle of least privilege.

Prevention & Best Practices

Always Be Explicit with Fetch Options

Never rely on browser defaults for security-sensitive fetch properties. Treat every cross-origin fetch call as a potential attack surface and explicitly declare:

fetch(url, {
  method: 'POST',
  mode: 'cors',           // Enforce CORS protocol
  credentials: 'omit',   // Never send credentials to third-party domains
  body: data
});

Principle of Least Privilege for Credentials

Ask yourself: does this external endpoint need the user's cookies or auth headers? For the vast majority of third-party API calls (analytics, summarization, enrichment services), the answer is no. Default to credentials: 'omit' and only upgrade to credentials: 'include' when there is an explicit, documented need.

Consider Subresource Integrity and Certificate Pinning

For a widget library that fetches from a fixed external URL, consider:
- Subresource Integrity (SRI) for any static assets loaded from the external domain.
- Certificate Transparency monitoring to detect unexpected certificate changes for a11y-widget.jerit.in.
- If the architecture allows, proxying the summarization request through your own backend rather than making it directly from the browser eliminates the client-side MITM surface entirely.

Library Authors: Audit All External Fetch Calls

If you maintain a JavaScript library that is distributed to downstream consumers, audit every fetch(), XMLHttpRequest, or axios call that targets an external domain. Your users inherit your network security posture. A single missing credentials: 'omit' in your library can affect thousands of end-user sessions.

Relevant Security Standards

• OWASP A02:2021 – Cryptographic Failures and A07:2021 – Identification and Authentication Failures both cover credential exposure scenarios like this one.
• CWE-346: Origin Validation Error — failure to properly validate or enforce cross-origin request restrictions.
• OWASP CORS Cheat Sheet provides detailed guidance on correct CORS configuration for both client and server.

Key Takeaways

• fetch() to third-party domains in script.js must always include credentials: 'omit' — the external summarization endpoint at a11y-widget.jerit.in has no legitimate need for user session credentials.
• Omitting mode: 'cors' is not "safe by default" — it leaves CORS enforcement implicit and inconsistent across environments; always declare it explicitly.
• Library-level vulnerabilities have multiplied impact — a single insecure fetch in a distributed widget affects every downstream consumer, not just one application.
• HTTPS alone does not prevent MITM credential leakage — transport encryption protects the channel, but browser-level credential controls protect what gets sent through that channel.
• The fix required only 2 lines of code — but those 2 lines eliminate an entire class of credential-leakage attack for all users of this widget.

How Orbis AppSec Detected This

• Source: Text content submitted by the user to the widget's summarization feature, triggering the fetch call at script.js:1152.
• Sink: fetch('https://a11y-widget.jerit.in/summarize', { method: 'POST', body: formData }) in script.js at line 1152 — a cross-origin POST with no explicit CORS mode or credential controls.
• Missing control: No mode: 'cors' to enforce cross-origin protocol compliance, and no credentials: 'omit' to prevent unintended forwarding of cookies or auth headers to the third-party domain.
• CWE: CWE-346 — Origin Validation Error (failure to properly enforce cross-origin request restrictions).
• Fix: Added mode: 'cors' and credentials: 'omit' to the fetch options object at script.js:1154–1155, enforcing strict browser-level CORS compliance and eliminating credential leakage to the external endpoint.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

A two-line fix — mode: 'cors' and credentials: 'omit' — closes a meaningful attack window in this accessibility widget. The vulnerability illustrates a common pattern in JavaScript development: developers correctly choose HTTPS for transport security, but overlook the browser-level controls that govern what gets sent and under what cross-origin rules. For library authors especially, these defaults matter enormously because your network security decisions propagate to every application that depends on your code.

When writing fetch calls to external services, treat explicit CORS mode and credential control as non-negotiable defaults, not optional enhancements. Your users — and their users — are counting on it.

References

• CWE-346: Origin Validation Error
• OWASP CORS Cheat Sheet
• MDN Web Docs: fetch() – credentials option
• MDN Web Docs: fetch() – mode option
• Semgrep rules for insecure fetch patterns
• fix: the widget makes unauthenticated https fetch ca... in script.js