It’s a little more complex than that. If you want the app on the user device to be able to dump data directly into your online database, you have to give it access in some way. Encrypting the transmission doesn’t do much if every app installation contains access credentials that can be extracted or sniffed.
Obviously there are ways around this too, but it’s not just “use TLS”.
Wouldn’t some sort of proxy in between the bucket and the client app solve this problem? I feel like you could even set up an endpoint on your backend that manages the upload. In other words, why is it necessary for the client app to connect directly with the bucket?
Maybe I’m not understanding the gist of the problem
Exactly, it’s not necessary. It’s bad / lazy design. You don’t expose the DB storage directly, you expose a frontend that handles all the authentication and validation stuff before accessing the DB on the backend. That’s normal Client-Server-Database architecture.
Encrypting the transmission doesn’t do much if every app installation contains access credentials that can be extracted or sniffed.
Encrypt the credentials then? Or OAUTH pipeline, perhaps? Automated temporary private key generation for each upload (that sounds unrealistic, to be fair)? Can credentialing be used for intermediary storage that encrypts the data on that server and then decrypted on the database host?
Clearly my utter “noobishness” is showing, but at least it’s triggering a slight urge to casually peruse modern WebSec production workflows. I am a DNN researcher. Thus, I am far removed from customer-facing production environments, and it shows.
Any recommendations on literature or articles on how engineers solve these problems in a “best practices” way that you can recommend? I suppose I could just look it up, but I thought I’d ask.
Edit: I don’t know why I’m down-voted. My questions were sincere.
It’s a little more complex than that. If you want the app on the user device to be able to dump data directly into your online database, you have to give it access in some way. Encrypting the transmission doesn’t do much if every app installation contains access credentials that can be extracted or sniffed.
Obviously there are ways around this too, but it’s not just “use TLS”.
Wouldn’t some sort of proxy in between the bucket and the client app solve this problem? I feel like you could even set up an endpoint on your backend that manages the upload. In other words, why is it necessary for the client app to connect directly with the bucket?
Maybe I’m not understanding the gist of the problem
Exactly, it’s not necessary. It’s bad / lazy design. You don’t expose the DB storage directly, you expose a frontend that handles all the authentication and validation stuff before accessing the DB on the backend. That’s normal Client-Server-Database architecture.
Encrypt the credentials then? Or OAUTH pipeline, perhaps? Automated temporary private key generation for each upload (that sounds unrealistic, to be fair)? Can credentialing be used for intermediary storage that encrypts the data on that server and then decrypted on the database host?
Clearly my utter “noobishness” is showing, but at least it’s triggering a slight urge to casually peruse modern WebSec production workflows. I am a DNN researcher. Thus, I am far removed from customer-facing production environments, and it shows.
Any recommendations on literature or articles on how engineers solve these problems in a “best practices” way that you can recommend? I suppose I could just look it up, but I thought I’d ask.
Edit: I don’t know why I’m down-voted. My questions were sincere.