We don’t encourage application developers to call the Storage API directly from the client application for two reasons. First, it doesn’t scale on our end. It’s a free service, and the potential size of a week of data of an application is really high so this is a practical limit. We need the TTN public community network infrastructure to scale. In fact, the reason why the storage integration came this late, is exactly for this reason. Second, you don’t want your application access key in your client applications, especially not in browsers where they’re plain and visible in code or in any browser builtin network analyser. With the key’s messages right (the bare minimum for the storage integration), you can schedule downlink. It’s a very bad practice, regardless of how public your data is.
Currently there isn’t any. If we introduce this, we will announce that in time and probably contact application developers that are violating future defined new rules. Today it’s “best effort” as with anything in the public community network.
For the CORS, I would suggest a proxy that runs in your domain that fetches data from the Storage API and makes it available to your clients. You can do this server less in AWS and Azure, for example. You could do the same with MQTT to web sockets, although not server less. Both approaches allow you to use your own security mechanism.