Access-Control-Allow-Origin header missing in dev server for assets

[vkennke]

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

@angular-devkit/build-angular 19.1.4

Description

Starting with Angular 19.1.5, when running the development server using ng serve, the Access-Control-Allow-Origin header is no longer included in responses when accessing assets. In version 19.1.4, this header was still being sent with the value '*'.

This affects cross-origin requests to static assets served by the development server.

Minimal Reproduction

Repository for minimal reproduction:
[Link to Git Repository]

Steps to reproduce:

1. Clone repository and install dependencies:

git clone https://github.com/vkennke/angular-cors.git
cd angular-cors
npm install

2. Start dev server:

ng serve

3. Access http://localhost:4200/assets/test.txt and check response headers

Expected behavior:
Response headers include Access-Control-Allow-Origin: *

Actual behavior:
Access-Control-Allow-Origin header is missing from response

To verify this is a regression:

1. Edit package.json to set @angular-devkit/build-angular to 19.1.4:

"@angular-devkit/build-angular": "19.1.4"

2. Repeat steps 2-3
3. Observe that the Access-Control-Allow-Origin: * header is present

Exception or Error

No error is thrown, but the missing header prevents cross-origin requests from succeeding.

Your Environment

Angular CLI: 19.1.5
Node: 20.18.0
Package Manager: npm 10.8.2
OS: win32 x64

Angular: 19.1.4
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1901.5
@angular-devkit/build-angular   19.1.5
@angular-devkit/core            19.1.5
@angular-devkit/schematics      19.1.5
@angular/cli                    19.1.5
@schematics/angular             19.1.5
rxjs                            7.8.1
typescript                      5.7.3
zone.js                         0.15.0

Anything else relevant?

No response

[alan-agius4]

Can you explain why you need this header? If you're accessing resources from a different host, this behavior is expected. For more details, see: #29471.

[AndreKoepke]

Can you explain why you need this header?

Longer answer

In our case: We have a multi-frontend-system. The "main"-system runs somewhere in cloud (for example under "example.com") and loads its configured subsystems from various different domains ("exampleA.com", "exampleB.com", and so on).
Each subsystem has a defined entrypoint - the asset-file "manifest.json". Have a look at scion-workbench for more details.

For developing-purposes it is necessary that we can use the "manifest.json" from our local environment. We can say at domain "example.com" that one manifest can be found at localhost. Then the system tries to load the "localhost:4200/assets/manifest.json" file while the webpage is running under "example.com".

I will have a look at #29471 tomorrow. Maybe it solves our problems.
For us, it was a big surprise that jumping to the next patch release causing these kinds of troubles.

[vkennke]

Patch versions should never introduce breaking changes.

Our workaround is to set the header manually.

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "headers": {
              "Access-Control-Allow-Origin": "*"
            },

[AndreKoepke]

Can you explain why you need this header? If you're accessing resources from a different host, this behavior is expected. For more details, see: #29471.

I tried to set

"serve": {
      "builder": "@angular-devkit/build-angular:dev-server",
      "options": {
        "allowedHosts": ["example.com"]
      },

but it won't work. I got a warning "The "allowedHosts" option will not be used because it is not supported by the "@angular-devkit/build-angular:application" builder.", is it already released?

The workaround of @vkennke works well.

[alan-agius4]

The warning is no longer relevant and should be removed, setting the allowedHosts. I did some further digging and indeed the Access-Control-Allow-Origin is not added in this case.

@vkennke, you're right that patch updates should avoid breaking changes. However, in this case, it was necessary to address a security vulnerability in Vite.