groldan
commented
1 year ago ok I don't know much about this topic so I had to ask ChatGPT, here's what she said:
Bypassing CORS limits by using a proxy on the same domain as your web application is technically possible, but it's important to understand the implications and potential security risks involved.
When you set up a proxy on the same domain, requests from your web application are sent to the proxy server, which then forwards those requests to the intended cross-origin domain. The response from the cross-origin domain is then sent back to your web application via the proxy server.
By doing this, you effectively avoid the Same-Origin Policy restrictions enforced by the web browser since the requests are originating from the same domain. However, it's crucial to consider the following points:
Security: By bypassing CORS, you are intentionally circumventing a security measure designed to protect users. It's important to thoroughly assess the security implications of this approach and implement proper security measures to protect against potential vulnerabilities.
Trustworthiness: You will be acting as an intermediary between your web application and the cross-origin domain. This means that you will have access to the data being exchanged, including potentially sensitive information. Users and the cross-origin domain need to trust your proxy server to handle their data securely and responsibly.
Scalability and performance: Introducing a proxy server adds an additional layer of complexity and potential points of failure to your system. It may impact the scalability and performance of your application, depending on how well the proxy is designed and managed.
Maintenance and updates: Running and maintaining a proxy server requires ongoing effort and attention. You need to ensure that the proxy server remains up to date with security patches and updates to mitigate potential vulnerabilities.
Before deciding to bypass CORS limits with a proxy on the same domain, carefully evaluate the necessity and potential risks. In some cases, it might be more appropriate to explore other alternatives, such as implementing server-side solutions or working with the owners of the cross-origin domain to enable CORS on their servers.
Since the gateway is already a proxy on its own, given the case there's such a remote service, we could have instructions on how to add a route predicate to the gateway's config, and that's it?
Like in, I need a webapp, say Mapstore, to access https://a.remote.service/wms/**, I could just add a route to the gateway at, say /fcors/a.remote.service/wms/** that targets https://a.remote.service/wms/**? or am I missing something?
pmauduit
edevosc2c
fvanderbiest
landryb
f-necas
On the Security-Proxy, there is a /proxy/ endpoint which takes a url as a GET parameter, in case a remote service does not provide CORS headers allowing to get the resource without going through a XHR proxy: https://github.com/georchestra/georchestra/blob/master/security-proxy/src/main/java/org/georchestra/security/Proxy.java#L308-L331
The gateway does not provide such an endpoint ; if we need to implement such an ednpoint, the same security concerns should be be taken into consideration (avoid giving access to internal services - rancher-metadata, AWS metadata service, k8s equivalent, direct access to exposed services internally ...).