CLI CORS Proxy not changing origin, still get 403 on API reqs?


Yes, I’ve found a ton of stuff similar but still not resolved for my instance. I would like to avoid killing the browser side security and instead let the proxy do its job but I fear I’m missing some inane detail in the setup and I’m no CORS expert by any means.

So, what I get…a 403;

Failed to load http://localhost:10000/some/rest/endpoint: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.

Wherein localhost:10000 is my api url, and :4200 is the default Angular CLI instance.

So I config a proxy as I’d expect to as such in the angular.json;

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "angular-proj:build",
            "proxyConfig": "./proxy.conf.json"

and add a proxy.conf.json;

    "/some/rest/*": {
      "target": "http://localhost:10000",
      "secure": false,
      "changeOrigin": true,
      "logLevel": "debug"

I serve it up and even flag the proxy.conf which the CLI serve confirms;

[HPM] Proxy created: /some/rest -> http://localhost:10000 etc…

….except I still get the 403, and still see in the Request* headers;

Host: localhost:10000
Origin: http://localhost:4200

So my question is, what inane detail am I missing here? I don’t want to asterisk out the requests on all origins, and I don’t want to shut off the browser checks, I would much prefer to have this nicely bundled up in the serve config like I’m doing so another pair of eyes are more than welcome. Cheers

ADDENDUM: My GET’s seem to go through fine however something like a Access-Control-Request-Method: POSTshows as Request Method: OPTIONS and that’s where I get my 403…why would a POST become an OPTIONS??

ADDENDUM #2: Worth mentioning, I get this issue in Chrome / Firefox but everything is kosher in Edge???

ADDENDUM #3: This is running serve as --aot=true with proxy.


Issue was unique found by digging more. Figured out there was a hidden conditional in a chained config on the server side (aspnet api v1) for OPTIONS looking for UrlReferrer.Authority that’s not present on say a fresh first-time instance.

Pulled it out, changed Access-Control-Allow-Origin accordingly, and off to the races.


Answered By – Chris W.

Answer Checked By – David Goodson (AngularFixing Volunteer)

Leave a Reply

Your email address will not be published.