If i store the secret kyes on firebase, and send to the user only if is logged is a good idea? The app can be debugged and haked fom safari for examples?
Cordova apps are insecure by nature. Directly from their documentation on security:
Using firebase is great for proof of concept but if you have to store your private keys to Firebase’s API inside the app in order to use it, you’re opening yourself up to someone gaining access.
We have our own Oauth 2-based API server that we route all calls to/from. Mobile app users essentially request an access token via their username/password, and that token gets stored in the app. I can revoke access tokens. I can also place role-based access controls on each token. Theoretically, if my security is as robust as I have planned (I’m not naive enough to think it is perfect) the worst thing someone could do is get a valid access token assigned to someone else and start doing user actions as that person. But without gaining access directly to my API server they can’t get my third party private keys (like the keys you use to send/retrieve data from Firebase), and therefore can’t make requests to these services as my app.
Another deterrent is to obfuscate your code (run it through an minifier/uglifier). This doesn’t prevent reverse-engineering but it will make it more difficult.
OMG!!! Firebase work similar to yours Oauth 2-based and he has internal access rules configurable via dasboard. But i haven’t a back end server and i wouldn’t set up one only for upload images…
I try to unpack an ipa from an app made with ionic unzip it, show the content package and inside you have the www folder with inside ALL of your code!!!
@mhartington suggestions or best pratice for managing security on cordova apps??? the olny solutions is having a remote backend server?
How to store APP, API keys for Ionic app securely
As for all web apps, the code is freely accessible, so you only have the backend to store any secret (encryption key or such).
I wonder how important it really is to lock down the client/app keys for a service such as parse.
I mean, those keys are meant to be treated as public anyway and are not inherently secure (the one you want to protect is the master key in Parse’s case).
Shouldn’t your application in these BaaS’ be locking down all of your classes in the schema on a per-class or user-list basis? It seems like that is the paradigm Parse is pushing.
If that’s the case, even if a reverse-engineer is able to retrieve my client/app keys, what could they really do? If an app uses user authentication, you would need a session key to act as a user (assuming all backend objects are locked down from public access).
The worst that could happen is they could act as a normal user, but try to probe arbitrary permutations of your app API’s. IF you secured them correctly it should be not be a problem.
I think I’ve seen this type of thing in play with SnapChat, where 3rd party devs have written python wrappers around the snapchat API, you can then log in and automate SnapChat actions.