What are the cons and the pro for handling CORS in infrastructure or application ?

I mean is it better to setup CORS on my nginx/apache/tomcat ? or to handle it by coding in my application ?

I have three API REST running with their own language (java spring, express and php) behind a nginx reverse proxy. I have access to the code and to the nginx configuration.

When do i must avoid to handle CORS in my infrastructure (configuration)? When do i must avoid to handle CORS in my application (code)?

2 Answers 2


I don't think there is a general answer to this question.

If you have a web api that should offer differing subsets of functions to differing clients then you may wish to use CORS coupled with authorisation configuration information to implement this. This may especially be the case if for some reason you do not fully trust the channel and have sensitive data. In this case the pre-flight CORS request will prevent the data from being transmitted at all.


Complementing the answer from @sentinel, seems that there isn't a wide-convention for placing the CORS headers. I'd say that:

I'd place the logic in the server if:

  • The infra relies on a different team within the company and I prefer not to delegate it.
  • I need to build dynamic whitelist of hosts, depending on server logic (never seen this scenario though)

I'd place the logic in the infra if:

  • Other communication-related headers (for instance API Keys) are handled in another layer, this way I'm keeping just business logic in the server.

Anyway, these aren't hard rules, and both options are correct I guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.