CORS Header for REST API

[kettenbach-it]

Hi Mathieu,

I started playing around with Angular to build a web ui (SPA) for the MiniDSP Flex. Thanks to your openapi.json and openapi-generator, this is pretty easy. Thanks for that good work!

I have a request: would it be possible to have the API server send a CORS header: Access-Control-Allow-Origin: *

Otherwise, a browser with an SPA will deny access to the API and awkward constructions such as a proxy are required, which significantly degrade the UX of the ui-project.

Best regards Volker

[kettenbach-it]

I fixed it. Please merge PR https://github.com/mrene/minidsp-rs/pull/573

[mrene]

I see a few options for this:

• Whichever server is serving up the SPA can most likely already do a reverse proxy to the API itself
• minidsp-rs could have a configuration option to serve some static files at the root directory, which would simplify deploying an SPA
• minidsp-rs could be made configurable to allow CORS for a specific domain pattern (as suggested in my review of #573)

[kettenbach-it]

• Proxy@UI-Server: It may be correct in individual cases that the UI is delivered by the server that also executes the API. But in general you can't expect that: the UI could also be on a different server or no server at all, for example, but implemented in the form of an app. I'm also considering turning my Angular UI into an app (using Ionic). Furthermore, I'd like to point out that CORS headers don't create real security: they only prevent current browsers from calling a "foreign" API. Outside the browser context, or with a browser that has CORS turned off (which is trivial), a public API can be used by anyone. If you expose this API to the internet: good luck. But the protection of the API itself is not the task of CORS. This must now be done differently. Last but not least, a proxy is another component in the system that needs to be installed and maintained. I would try to avoid that. Modern architectures follow the KISS and separation of concerns pattern.

• minidsp-rsserving the SPA: I fully agree with that and I would provide and help integrate the UI for that as well. But please note the first point above: an app makes a lot of sense and I would also try this in addition. However, I think this is a different topic and this should be discussed in an appropriate issue with appropriate PRs. Just open one if necessary. For my part, I always keep issues and PRs strongly focused on a specific topic: in this case it's CORS for the API.

• Options for CORS in minidsp-rs: I think that makes sense as well and I can understand your desire for me to do this. But I can not do this sensibly: I do not know your software and have never developed in Rust. Even if I could do - given my background - it in principle, it would be time consuming for me and I have little time for such projects. Since you know your software very well and already implemented code for working with option, I suggest you build the two options suggested in the PR yourself. You can add your commits to it. For me it was important to have an API with CORS (which I have now) so I can play with the UI using the real API.

[mrene]

I can look at adding cors options to the configuration.

Regarding CORS and security, I want to point out that security is always relative to a threat model. If we assume that you have direct network access to the device, then it is true that CORS does not bring any extra security, because it is not designed to mitigate against local attackers. When deploying systems, we make assumptions like "local network devices cannot be accessed by remote attackers because they are behind NAT and firewalls, etc."

The web, however, is designed for to load websites that are basically untrusted programs running in a sandbox. CORS is a mechanism by which browsers validate that third party servers are designed to accept requests from such untrusted websites. Without Access-Control-Allow-Origin, a website serving you advertisements (for example) would have the permission to call into your minidsp-rs instance and change your configuration, even if you do not expose its API to the internet, because the code runs in your browser, and your browser essentially acts as a reverse proxy allowing the third party website access to your local network resources. (Of course it needs to know the local IP, and some browsers mitigate against this because it's been used to exploit vulnerabilites in home routers and IOT devices with poor security, but it's a possible attack surface).

In the non-hypothetical real world this would most likely happen due to some phishing attempt, and while your home theather system might not be a valuable target for a sophisticated cyber attack, it's nice to have some same defaults so that things aren't completely wide opened, and to let users control these parameters so they can make informed decisions about the security of their networks.

This being said, this is a hobby project that doesn't have much resources, so the features around security are pretty limited, but at least there are sane defaults, the API is not exposed to the local network in the default configuration, etc.

Thanks for coming to my TED talk :sweat_smile:

PS: Mobile application frameworks that wrap web-based application code usually have a native way to bypass CORS altogether

[kettenbach-it]

I can look at adding cors options to the configuration.

Thx!