Permissive CORS policy in Dev Server enables cross-origin source code exfiltration

[aastikgakhar]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

The Angular CLI Vite-based development server explicitly configures a permissive CORS policy that reflects any requesting origin as Access-Control-Allow-Origin. This allows any malicious website visited by a developer to silently read the full HTTP responses from the local dev server.

While the dev server is intended for local use, this configuration allows for the exfiltration of application source code (JavaScript bundles), original TypeScript (via Source Maps), HTML templates, and API proxy responses by any third-party website the developer happens to have open in another tab.

Minimal Reproduction

Technical Details

The vulnerability exists in [packages/angular/build/src/builders/dev-server/vite/server.ts](https://github.com/angular/angular-cli/blob/main/packages/angular/build/src/builders/dev-server/vite/server.ts).

The current configuration uses origin: true:

const server: ServerOptions = {
    // ...
    cors: {
      origin: true, // This reflects the 'Origin' header from any incoming request
      preflightContinue: true,
    },
    // ...
};

Why this is a problem:

1. Host Validation Bypass: Even though Angular implements allowedHosts to prevent DNS rebinding, browsers allow fetch() requests to localhost from any origin. Because localhost is a valid host, the middleware passes it, and the CORS policy then explicitly gives the calling site permission to read the response.
2. Regression of Upstream Fix: This exact issue was recently patched in Vite (CVE-2025-24010). Vite 6.x+ now defaults to restricting CORS to local hostnames. By hardcoding origin: true, Angular CLI explicitly opts out of this security improvement.

Impact

An attacker-controlled website (e.g., a malicious ad or a compromised documentation site) can execute background JavaScript to:

• Download the entire application frontend source code.
• Access .map files to reconstruct original TypeScript logic.
• Read sensitive environment variables or configuration hardcoded for development.
• Exfiltrate data from proxied API responses if the developer has a proxyConfig active.

Steps to Reproduce

1. Start a default Angular project: ng serve (running on http://localhost:4200).
2. Simulate a cross-origin request from a malicious site using curl:

   curl -H "Origin: https://malicious-site.com" -I http://localhost:4200/

3. Observed Result: The response includes access-control-allow-origin: https://malicious-site.com.
4. Expected Result: The server should reject the cross-origin request or only allow trusted local origins.

Proposed Mitigation

Instead of a wildcard/reflective policy, the dev server should restrict the Access-Control-Allow-Origin header to the dev server's own origin by default.

Suggested change in server.ts:

cors: {
  origin: serverOptions.corsOrigins ?? `http://${serverOptions.host}:${serverOptions.port}`,
  preflightContinue: true,
},

Developers requiring cross-origin access for specific testing scenarios should be able to opt-in via a cors configuration in angular.json, rather than having it enabled for all users by default.

Additional Context

Reference to the upstream Vite advisory: [GHSA-vg6x-rcgg-rjx6](GHSA-vg6x-rcgg-rjx6)

Exception or Error

Your Environment

Latest

Anything else relevant?

This issue was previously shared with the Google Security Team (https://issuetracker.google.com/issues/497425223), who suggested moving the discussion to this public tracker.