I am working on a React web app with a Firebase back end.
I was thinking about the security implications of accessing and updating the database directly versus accessing and updating the database with the use of back end functions like Firebase Cloud Functions.
Is it possible for malicious users to change the source code of the web app in such a way that they can alter the database queries once the web app has been built for production?
Yes, that is quite possible and quite common. You should not rely on the source code of your app to ensure your business rules.
Instead you'll want to rely on a combination on authentication and authorization to secure your data.
Authentication means that you ask the user to sign in, so that you know who's performing a certain operation. In Firebase you'll want to use Firebase Authentication for that. If you don't want to prompt the user for credentials, you can use anonymous authentication.
Once you know the user, you can ensure that they can only perform operations they are authorized for. You could do this in a custom backend, like Cloud Functions. But I'd always first consider Firebase's built-in security rules. These are evaluated server-side, and provide a fairly simple way to authorize access. Since the syntax depends on which database you use, here are the docs for Firebase Realtime Database and for Cloud Firestore.
Also see:
How to prevent other access to my firebase
Swift: Firebase: How to ensure no one can access my db except my app
How Secure is Firebase Real-time (Online) database for Android?
Related
There is plenty of tutorials and articles on this precise question but each one contradict the previous one,
I'm trying to make a signup and login reactJs pages with Firebase js sdk on the frontend, that's what I found most of youtubers devs do,
And then I found that is not secure (doing the authentication on client side).
You should use the Firebase Admin SDK (firebase.google.com/docs/admin/setup) on Firebase Cloud Functions or a self-hosted server in that case. Everything else would just be a dirty hack – PRSHL source
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves. source
I really want to understand if it is not secure to use it on the client side, Why does firebase provided it in the first place ?? or is there another way to properly write the auth using firebase js sdk on the frontend ? of course without using admin sdk
Or should I use firebase js sdk on the backend with express ?
I only want clear and detailed answers please !!
My best guess is that you're confused between authenticating a user client-side and the fact that Firebase provides a client-side SDK for authenticating users.
Though all you have to do to use Firebase Authentication in your app is implement its client-side SDK, there are many more parts involved in the process - and quite a few of them run on secured servers.
It's just that Firebase (and the authentication providers it supports) have implemented the server-side of the authentication process for you already and made the variables parts of the process part of the configuration that you provide either in the Firebase console, the provider's web interface, and/or in the configuration that you specify when you initialize the Firebase SDK in your client-side application code.
From the comments you now added, the second is correct and explains exactly what the risk is:
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves.
So while you can safely create a user account on the client (a process known as authentication), marking them as an admin (a process known as authorization) has to happen in a trusted environment as otherwise any user could make themselves an admin.
I'm trying to build an app that works like a classic videogame, with some challenges that the user must complete in order to advance. Based on how the user solves the puzzles, he/she will gain XP points, badges etc. The user can quit the app and come back later, with an authentication system.
I'm planning to use Firebase Auth for authentication and Firestore for the database. It's the first time I use Firebase services in (somewhat) production environments, but I've been experimenting a lot with their services lately.
Firestore will be used to store a set of data for every user, but mainly his/her score. I'm somehow familiar with Security Rules in Firestore, and know how to make sure that only authenticated users can write to the db, perform data validation before giving write permissions etc.
However, there's one problem I cannot come up with: how can I be sure that the (authenticated) user will not use the browser console, or a custom API call to update his/her points and write them to the DB? Like in the first part of this video: https://www.youtube.com/watch?v=b7PUm7LmAOw&t
To sum up: my expected result would be that the (authenticated) user could update his/her score on my Firestore DB only by using the UI (i.e. solving challenges) and not by making a direct call to the DB. I thought of some other solutions (e.g. sending only user response - like answers to a quiz - to the DB and then updating the scores server-side with Cloud Functions), but it seems to me that I'm over-complicating a simple issue.
I've watched and read a good amount of guides on security in Firestore: they do a good job explaining how to secure an app from un-authenticated hackers, but I am yet to find a guide on how to defend the app against unwanted behaviour from authenticated users.
Thank you in advance for any guidance on this, deeply appreciate it. Stay safe :)
UPDATE: looks like the only way to manage data flow to the DB when you can't "trust" the authenticated user is using Cloud Functions. Thanks!
Listen to score, points, badges in real time using Firestore. You may set the security rules to these fields as READ ONLY for an authenticated user, setting write permission for a service user (that will be used in your cloud functions).
Send Quiz answers using a cloud function, that will be processed using your service authenticated user (with write permissions to the collections).
Thus, your cloud function may be responsible for checking answers and preventing user abuse from console and other methods.
I think from searching the web this is not technically possible but I want to ask again in case I'm missing something.
I have an app that uses Firebase. Reading and writing is locked down through security rules for authorised users only but there's certain information I want unauthorised users to be able to access (so I don't have to put a login wall in front of them, influencing churn).
What I want to know is, is there any way of locking down this read access that only my app can call the DB? I know I can lock down domains to prevent someone writing localhost scrapers but what's to stop someone cloning and re-skinning an app and pointing it to the same back end? Is it possible to achieve this using your certificates fingerprint?
There is no way to limit access to your database to just your app. That just doesn't match with the cloud-based nature of the Firebase APIs. Anyone that knows the URL of your database can in in principle access it, and security rule are the way to ensure all access is authorized.
Note that security rules are not an all-or-nothing approach: you can require sign-in for some parts of your database, while leaving other parts publicly readable. But you can't make the publicly readable parts only be readable by your own app.
Some previous questions on the same topic:
how to make sure only my own website (clientside code) can talk to Firebase backend? (pretty much my go-to answer for this)
How to allow only my app to access firebase without a login?
Restrict Firebase database access to one Android app
How to allow only my app to access firebase without a login?
Update: since May 2021 you can actually restrict access to just users of your App by implementing Firebase App Check.
I have found a solution that maybe helps you or anyone that have a similar question. I answered it in this question:
Restricting Cloud Firestore to a specific domain
I have a Django web application with a postgresql database on an AWS server.
I want to keep this database in sync with a nosql cloud firestore database. We're using cloud firestore as the backend for a mobile app.
This means that every form update or new object that is added to the web app needs to be in sync with cloud firestore.
I'm able to update cloud firestore using the Python SDK when each form is submitted via the web app. However, I want to know if this is the best method to keep these two databases in sync. Each time a form is submitted, I have to import the firebase SDK, and then use the methods to update cloud firestore. Obviously, this will take time, but I'm unsure if this method is better, or if using the JavaScript SDK will be better. In essence, which method will perform better?
When you are doing that from python SDK the read and write to cloud fire storage is done from the server means if you have x request and y number of users doing that, your server has to do x*y request to Cloudflare storage. in this case, your transaction from the server will be heavily based on a user basis but you can use admin SDK in python and give only admin to access to DB.
If you want to use js for the same then request will be shared by users and the server will be free but each user should have access to DB write and read, you have to be more careful about authenticating users.
so if its all read requests and user-based filters are done well use from js, if you have doubts on authentications or you don't want to take a risk in that use from python.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html