If you'd like to learn more about CORS and why it is needed on the web, please refer to MDN's CORS documentation page
To reduce security concerns, we do not support adding CORS in the container. However, there are well known web development patterns that allow us to call APIs from the browser while still respecting CORS headers.
There are many established patterns for dealing with CORS headers. We will explain two common patterns, however this is not an exhaustive list. The solution you ultimately end up going with will depend on your web technologies and current application architecture.
CORS specifically was made to protect against browser-based vulnerabilities.
You can access the Private AI container's APIs from an API gateway or backend without any CORS headers required. That API Gateway or backend can then in-turn have CORS configured for the domain of your front-end application.
In this diagram, we've set up an API Gateway to allow our website's (website.com) origin to have access to the api-gateway.com resources.
Because CORS isn't required for server-to-server interaction, the connection from
api.private-ai.com does not need require CORS headers for it to be successful.
As the same-origin policy is implemented by internet browsers and not enforced within server-to-server communication, you can use a proxy server to call the external API.
A proxy server acts as a middleware between the client and the server. Instead of making a request from the client to the external API directly, you can make a request to the proxy server. The proxy server will make a request to the external API for you and return the response that it receives from the external API.
For example, the popular build tool Vite allows you to create a proxy server while you are locally developing your front end application. Details about the proxy server can be found in the vite documentation.