Zitadel intercepts with wildcard CORS headers which are not configurable

Hi,
It looks like for the most of the url paths zitadel intercepts/adds its own CORS headers (Access-Control-Allow-Origin header for e.g.) which is the wildcard one (allows all). Which means - whatever "Origin" header the browser is sending, the CORS will ALWAYS accept it.
Also we haven't found the way to configure this setting (either to enable/disable it, or to modify).
The url paths for which the zitadel injects CORS:
"/.well-known/",
"/oauth/",
"/oidc/",
"/idps/callback/",
"/saml/",
<all API endpoints>

What was the intention for this decision? Can this be considered as a security flaw?

Ask Inkeep•11/25/25, 7:23 AM

Hi @RAleksejuk, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•11/25/25, 7:23 AM

Answer

ZITADEL's OIDC endpoints are configured to allow all origins by design. (1) The CORS configuration includes AllowOriginFunc: func(_ string) bool { return true }AllowOriginFunc: func(_ string) bool { return true }, which means any origin is accepted.

This is intentional behavior for the OIDC endpoints. questions-help-bugsCan Set Arbitrary CORS Headers Using ORIGIN Header (1) The Access-Control-Allow-Origin header in responses mirrors the value passed in the Origin header, and this value is not filtered by any allow list. questions-help-bugsCan Set Arbitrary CORS Headers Using ORIGIN Header

There is currently no configuration option to modify or disable this CORS behavior for OIDC endpoints. (1) The configuration of your application is not relevant for the OIDC endpoints, as they have their own predefined CORS settings.

From a security perspective, this design choice aligns with OAuth 2.0 and OpenID Connect specifications where the security model relies on other mechanisms (redirect URI validation, PKCE, state parameters) rather than CORS restrictions. (3)

If you need more specific guidance about whether this fits your security requirements, I'd recommend reaching out through Contact , GitHub , or Discord .

Ask Inkeep•11/25/25, 7:23 AM

To learn more, see the sources I considered:

[1] CORS policy : preflight issue
questions-help-bugsCan Set Arbitrary CORS Headers Using ORIGIN Header
[3] OpenID Connect Endpoints in ZITADEL

Ask Inkeep•11/25/25, 7:24 AM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep To learn more, see the sources I considered: [[1] CORS policy : preflight iss...

Ask InkeepAPP•11/25/25, 7:26 AM

Got it. Tagging @Rajat for additional help.

RAleksejukOP•11/25/25, 7:30 AM

@Rajat
I wasn't able to find an evidence, that "Allow any domain" CORS headers aligns with OAuth 2.0 and OpenID specifications. I would say the opposite. Allowing wildcard origins (

) can turn otherwise safe APIs into cross-site data leaks.

Rajat•11/25/25, 1:08 PM

hey @RAleksejuk thanks for the pointing that out, I will take a look.

RAleksejukOP•12/1/25, 1:46 PM

Any updates? @Rajat

Rajat•12/2/25, 10:11 AM

hey @RAleksejuk no but I got to read. alot about it and your assessment is correct, I have raised it intrenally and will back to you on it.

RAleksejukOP•12/4/25, 9:10 AM

Please kindly keep me informed on any news. Thanks in advance

RRAleksejuk Please kindly keep me informed on any news. Thanks in advance 🙏

Rajat•12/4/25, 11:23 AM

hey @RAleksejuk I got a response from the team and it goes like this

CORS is a safety-measure by the client. They are returned in the response headers. Meaning the server has already sent the response (with potential information to the client.
The client then has to evaluate whether it wants to allow the response to be shown. If someone calls an endpoint using a tool like cURL or Postman, cors validation can be disabled. Since we want web-applications to call our api, a lot of origins will call the endpoint.
We could set the cors headers depending on the client for which a request is made. This would block other web-applications from making the request as the browser will block it. But any cURL request will still show the response. Native clients will probably also ignore these headers since they are not calling from an origin.
Apart from the oidc endpoints which are typically called by web-applications, we also have a bunch of api endpoints which will be called from other backend services. These will also ignore the CORS.
All our endpoints are protected using an authentication header on the request. This way the server will evaluate whether the client may receive the response.

In short: no this is not a security issue imho. I do think this was a design choice

RAleksejukOP•12/4/25, 12:30 PM

Thanks for the official reply

Rajat•12/5/25, 2:50 PM

hey @RAleksejuk you can mark my response with

and it will auto close this thread.

RAleksejukOP•12/10/25, 7:40 AM

I am trying to tag it with

, but then it disappears auto-magically :). I am not into dicord honestly, not sure why