CORS issue with Azure Application Proxy

Question

CORS issue with Azure Application Proxy

Erik Andersson 26

I currently have two on-premise apps, one is the web app and the other is the API for it. Lets call them app.customdomain.com and api.customdomain.com. These work on the internal network but I want to publish them externally through the Application Proxy we have set up.

Config:

I've added these apps to the proxy using a wildcard app with the URL"https://*.customdomain.com" with 2 application segments added with URLs "https://app.customdomain.com" and "https://api.customdomain.com" and added the following CNAMe records to our external DNS:

app.customdomain.com -> `

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-20T13:16:22.64+00:00

Hello Erik Andersson,

Please confirm if you have any further queries on this or good to close this question
Erik Andersson 26 Reputation points

2026-03-23T16:01:13.9833333+00:00

Thank you for the answer, I just saw now that for some reason 70% of my question disappeared where I wrote everything we've already tried...

But anyway this is what confuses me as we have tried setting "Access-Control-Allow-Origin: *" so that shouldn't be the issue.

I can also see that when the pre-flight OPTIONS is sent I get a response that clearly states the origin is allowed so it goes through the proxy and the API handles the request without issue.

I've also tried adding the CORS-rules to the app in Azure according to Microsofts guide on how to solve this under Option 6 here: https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-understand-cors-issues

It works internally but not externally through the proxy.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-25T09:38:06.5266667+00:00

Hello Erik Andersson,

Since the preflight request is succeeding and your API is already returning the expected CORS headers, this points to what the browser receives after the request goes through Application Proxy.

Please check the external request in DevTools (Network tab) and review the final response headers, as that’s what the browser evaluates.

Also check the full request flow for any redirects or authentication responses before the API call completes. If there’s a redirect in between, those responses typically won’t include CORS headers, which can cause the browser to block the request even though the API itself is configured correctly.

The difference between internal and external access usually comes down to this
Erik Andersson 26 Reputation points

2026-03-27T12:50:22.45+00:00
Yes, I am checking the requests in DevTools every time and there's an OPTIONS request going through that gives the status 204 and responds with:

Access-Control-Allow-Origin: https://app.customdomain.com Access-Control-Allow-Methods: GET Access-Control-Allow-Headers: Authorization

Then the GET is sent to api.customdomain.com/resource which responds with status 302 and the following in the console tab:

Access to XMLHttpRequest at 'https://api.customdomain.com/resource' from origin 'https://app.customdomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

So for some reason the 'Access-Control-Allow-Origin' disappears even though it just responded with it.

The 302 response has a header called Location that's set to https://login.microsoftonline.com/[...], could this be because of the MS login page or the proxy doing some weird redirect?
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T12:56:21.21+00:00

Hello Erik Andersson,

This aligns with what you’re seeing.

The preflight succeeds, but the GET returns a 302 to login.microsoftonline.com. That response doesn’t include Access-Control-Allow-Origin, and since the browser evaluates that response, the call gets blocked.

This indicates the request is being redirected for authentication before reaching the API. With Application Proxy pre-auth enabled, this is expected and doesn’t work for browser-based API calls.

The request needs to be authenticated upfront (for example, using a token) so it doesn’t trigger the redirect.

Reference: https://learn.microsoft.com/entra/identity/app-proxy/application-proxy-understand-cors-issues
Erik Andersson 26 Reputation points

2026-03-27T13:35:07.2766667+00:00

But as long as Application Proxy pre-auth is enabled then it will always redirect to the auth page correct?

So the solution is disabling pre-auth for only the API which is impossible with the solution in the reference you sent. I've read that multiple times by the way, and it clearly states that I should set up a "Complex app" using application segments in a wildcard app to solve pre-auth issues which is exactly what I have done but it doesn't work as stated so I don't understand what's wrong.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T13:41:05.8133333+00:00

Hello Erik Andersson,

Your understanding is close, but one small clarification.

Pre-auth does not always redirect. It redirects only when the request reaches the proxy without a valid session or token.

In your case, the GET call is unauthenticated, so the proxy returns a 302 to login.microsoftonline.com. That response doesn’t include CORS headers, so the browser blocks it. The request never reaches your API.

Your wildcard + segments setup is correct. That setup handles routing, not authentication behavior, so it won’t prevent this.

You’re also right that pre-auth can’t be disabled per segment in that model.

To make this work, the request needs to be authenticated before it reaches the proxy (for example, sending a token in the Authorization header). In that case, no redirect happens.

The other option is to publish the API separately without pre-auth and handle authentication in the API.

So, nothing is misconfigured here, this is expected behavior.
Erik Andersson 26 Reputation points

2026-03-27T15:36:09.7533333+00:00

Okay thank you, I tried turning off pre-auth and handling the auth in the app instead and that works fine.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T15:39:36.7533333+00:00

Hello Erik Andersson,

That makes sense. With pre-auth off, the request goes straight to your API, so there’s no redirect and CORS works as expected.

If this setup works for you, you’re good to proceed.

Let me know if you need anything else or good to close this question.

Answer accepted by question author

0 additional answers

Your answer

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-20T13:16:22.64+00:00

Hello Erik Andersson,

Please confirm if you have any further queries on this or good to close this question
Erik Andersson 26 Reputation points

2026-03-23T16:01:13.9833333+00:00

Thank you for the answer, I just saw now that for some reason 70% of my question disappeared where I wrote everything we've already tried...

But anyway this is what confuses me as we have tried setting "Access-Control-Allow-Origin: *" so that shouldn't be the issue.

I can also see that when the pre-flight OPTIONS is sent I get a response that clearly states the origin is allowed so it goes through the proxy and the API handles the request without issue.

I've also tried adding the CORS-rules to the app in Azure according to Microsofts guide on how to solve this under Option 6 here: https://learn.microsoft.com/en-us/entra/identity/app-proxy/application-proxy-understand-cors-issues

It works internally but not externally through the proxy.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-25T09:38:06.5266667+00:00

Hello Erik Andersson,

Since the preflight request is succeeding and your API is already returning the expected CORS headers, this points to what the browser receives after the request goes through Application Proxy.

Please check the external request in DevTools (Network tab) and review the final response headers, as that’s what the browser evaluates.

Also check the full request flow for any redirects or authentication responses before the API call completes. If there’s a redirect in between, those responses typically won’t include CORS headers, which can cause the browser to block the request even though the API itself is configured correctly.

The difference between internal and external access usually comes down to this
Erik Andersson 26 Reputation points

2026-03-27T12:50:22.45+00:00

Yes, I am checking the requests in DevTools every time and there's an OPTIONS request going through that gives the status 204 and responds with:

Access-Control-Allow-Origin: https://app.customdomain.com Access-Control-Allow-Methods: GET Access-Control-Allow-Headers: Authorization

Then the GET is sent to api.customdomain.com/resource which responds with status 302 and the following in the console tab:

Access to XMLHttpRequest at 'https://api.customdomain.com/resource' from origin 'https://app.customdomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

So for some reason the 'Access-Control-Allow-Origin' disappears even though it just responded with it.

The 302 response has a header called Location that's set to https://login.microsoftonline.com/[...], could this be because of the MS login page or the proxy doing some weird redirect?
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T12:56:21.21+00:00

Hello Erik Andersson,

This aligns with what you’re seeing.

The preflight succeeds, but the GET returns a 302 to login.microsoftonline.com. That response doesn’t include Access-Control-Allow-Origin, and since the browser evaluates that response, the call gets blocked.

This indicates the request is being redirected for authentication before reaching the API. With Application Proxy pre-auth enabled, this is expected and doesn’t work for browser-based API calls.

The request needs to be authenticated upfront (for example, using a token) so it doesn’t trigger the redirect.

Reference: https://learn.microsoft.com/entra/identity/app-proxy/application-proxy-understand-cors-issues
Erik Andersson 26 Reputation points

2026-03-27T13:35:07.2766667+00:00

But as long as Application Proxy pre-auth is enabled then it will always redirect to the auth page correct?

So the solution is disabling pre-auth for only the API which is impossible with the solution in the reference you sent. I've read that multiple times by the way, and it clearly states that I should set up a "Complex app" using application segments in a wildcard app to solve pre-auth issues which is exactly what I have done but it doesn't work as stated so I don't understand what's wrong.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T13:41:05.8133333+00:00

Hello Erik Andersson,

Your understanding is close, but one small clarification.

Pre-auth does not always redirect. It redirects only when the request reaches the proxy without a valid session or token.

In your case, the GET call is unauthenticated, so the proxy returns a 302 to login.microsoftonline.com. That response doesn’t include CORS headers, so the browser blocks it. The request never reaches your API.

Your wildcard + segments setup is correct. That setup handles routing, not authentication behavior, so it won’t prevent this.

You’re also right that pre-auth can’t be disabled per segment in that model.

To make this work, the request needs to be authenticated before it reaches the proxy (for example, sending a token in the Authorization header). In that case, no redirect happens.

The other option is to publish the API separately without pre-auth and handle authentication in the API.

So, nothing is misconfigured here, this is expected behavior.
Erik Andersson 26 Reputation points

2026-03-27T15:36:09.7533333+00:00

Okay thank you, I tried turning off pre-auth and handling the auth in the app instead and that works fine.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-27T15:39:36.7533333+00:00

Hello Erik Andersson,

That makes sense. With pre-auth off, the request goes straight to your API, so there’s no redirect and CORS works as expected.

If this setup works for you, you’re good to proceed.

Let me know if you need anything else or good to close this question.

Answer 1

Sridevi Machavarapu 33,820 Microsoft External Staff Moderator

Hello Erik Andersson,

Thanks for the update.

From what you’ve tested, the API is returning the correct CORS headers and the preflight request is working. The issue comes from the GET request returning a 302 to login.microsoftonline.com.

That response doesn’t include CORS headers, so the browser blocks it. The request is being intercepted for authentication and never reaches your API.

Your wildcard + segments setup is correct. It handles routing, not authentication, so nothing is misconfigured there.

Since it works after disabling pre-auth, that confirms the cause.

You can either keep pre-auth off for the API and handle authentication in the app, or keep pre-auth enabled and send the request with a valid token so no redirect happens.

So this is expected behavior for this setup, not a configuration issue.

Reference: https://learn.microsoft.com/entra/identity/app-proxy/application-proxy-understand-cors-issues

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-03-28T04:02:21.75+00:00

Hello Erik Andersson,

Please confirm if you have further queries on this.