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
Related
I don't have any idea how to implement this. After a bit of search I found out that medium keeps track of the browser and not the user, what is mean is you can access three free articles from each new browser on the same machine (if I am wrong do point it out). I am using React and Firebase for my website.
Edit: I was thinking along the lines of getting some kind of id which is unique to a browser. As cookies and local storage can always be bypassed.
I don't know if it's a clean way to do it but you can associate an IP to an unique counter. Or with a cookie but he can bypass that by cleaning the cookies
The answer would tightly depend on your application setup and especially on the service backing your front store.
If you are using a self-backed backend, for example a nodejs - express based server, within your route middleware you can access the remote address from the req.connection.remoteAddress request property along with the user-agent req.header('User-Agent') and forward these to your datastore being Firebase in this case.
If you are deploying your application to Google Cloud Function, you can then access the remote peer address using the fastly-client-ip request header and still forward this to your storage system.
Use javascript and implement a system that uses a cookie or local-storage to verify how many articles are read on your website.
On most of these websites however you are still able to bypass this limit by clearing the cache or using a incognito window.
To also limit these scenarios you can use a cookie in combination with an IP address, which has its own drawbacks, especially in corporate environments, and mobile connections where IP addresses are heavily shared or changed. Depending on your situation this may matter or not.
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 have a rather noob question that I can't seem to find the answer for. So I've heard that all electron apps can be turned into source code and then manipulated. So that leads me to my next question. If I'm connecting to a SQL database then what is keeping people from viewing source code, going in and doing whatever they want to the db? I mean once they see the source code the username and password are right there...Sorry if this is a silly question but I'm thinking of making something on electron that needs decent security. I've also heard php cannot be used. So... Any suggestions would be appreciated. I'm just wondering because Discord, whatsapp and such seem to do it somehow, but how?
Thanks!
Well, any information in any application can be reverse engineered, so I would suggest to not hardcode database passwords or any other critical credentials.
I assume Slack, Discord and others don't hardcode their DB passwords in app. Their desktop app don't "talk" directly to database, it's talking with some server-side application. You as a user have to provide credentials to your account. Communication is done through API which implies various restrictions based on your user privileges. This server-side application decides what you can and what you cannot do and translates your requests into DB operations.
So using those apps you don't go even near to their DB passwords.
If you want to do client application which should be able to do some operations on DB, I would suggest the same, split this application into two parts: ClientApp and ServerApp.
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
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)