CORS Errors when using Webservice in external website

@Harm Horstman  do you need any more help on this or did you resolve this already?

Hi @Erwin Ekkel,

We found a solution by installing the CORS module on IIS and add some settings in web.config which was quite easy.

Vincent Doppenberg recommended to not use the CORS module and advised us to setup a reverse proxy. 

I still like to know what is the disadvantage of using the CORS module?

Further details CORS module:
https://www.iis.net/downloads/microsoft/iis-cors-module 
https://learn.microsoft.com/en-us/iis/extensions/cors-module/cors-module-configuration-reference

Hello Harm,

It’s not so much about the disadvantage of CORS, I wouldn’t say that there is anything specifically wrong with CORS. However, it’s important to understand why CORS is necessary, which problem it solves and which problems (with the same cause) it does not solve.

All modern browsers adhere to what is known as the Same Origin Policy, which limits how a website is allowed to interact with other web resources. Simply put, it restricts websites from interacting with other websites (‘other’ meaning different domains) for security reasons. This affects requests made by the browser, but also if cookies are allowed to be included in a request, if the website is allowed to be embedded in an iframe, etc. All of these measures prevent common security risks such as Clickjacking and Cross Site Request Forgery.

So in short, browsers use SOP to protect users against security risks. Browsers do this by limiting the operating space of websites such that operations which are vulnerable to being abused are not available. CORS relaxes one of these limits, by extending the list of domain names from which requests can be made by a predefined list of “trusted origins”. However, CORS does not relax any of the other limits such as from which domains cookies may be sent or in which domains a website is allowed to be embedded. 

I usually advise against CORS, because fully solving the “cross site issue” often requires more than just CORS and sometimes even requires accepting a lower security standard. For some problems, such as which domains are allowed to embed Indicium, there are solutions similar to CORS, but we have no support for that at this time. So a feature like document previewing in the Universal GUI cannot work cross site right now. Since SOP only applies to browsers and not to server-to-server communication or things like Postman/Insomnia, and communication from browsers to Indicium is almost exclusively done by a GUI that cares about authentication sessions or previewing, CORS is nearly never the full solution. Because of these things, my general opinion is that whenever it is possible to use a reverse proxy instead of CORS, that is the superior, long-term solution. Especially considering that there are many other reasons to use a reverse proxy and many architectures even require one.

Now it your case it appears that just CORS might be sufficient. If so, then there is nothing necessarily wrong with that. But if authentication sessions or embedding becomes relevant, you will probably run into issues.

As a side-note I would strongly recommend against running Indicium in Development mode unless it is actually only used for development purposes.

I hope this helps.

Vincent,

Perfect, this is very clear now.

I will keep this in mind and discuss with my customer, how to continue with this.

Thank you very much.