Another thing to mention is that just because you are using Appwrite, doesn't mean a user will know you are using Appwrite. Sure they can keep track of the requests being sent, but that's a very rare case and usually only happens if you're storing super sensitive data that could be very expensive if grabbed by a threat actor.
Just because someone creates a local app with your package name, doesn't mean they know how your database is structured, or how your files are stored and linked. That is the information you need to make sure is concealed.
How are you paying for something it's not possible to pay?
I'm guessing he's planned his financials in a way that when pricing is implemented, he'll use the 15$ plan
Or maybe he's gotten in touch with someone and already has access to the paid version π π²
I see. For a paywall he could make what you said, set permissions to not allow access, not sure what to fear
yep. before i implemented the dual collections, I had just one collection and used Appwrite Functions to return appropriate data
So I wouldn't call the database.getDocument
from client. I would just run createExecution
that checked if a user has the authorization to view certain docs
Probably It's not even needed having a dual collection, just permissions and a team
But both methods work, so it's the same
I agree, it's just that I was very very new to Appwrite at the time and just did what I understood lmao
i am using 7$ digital ocean and 5$ digital ocean space , and now planned to move to appwrite 15$ plan
from when we can use 15$ appwrite plan?
When cloud ends beta
when can i expect , my app is fully ready for production
If all users of your app can save and delete app from your databases, why do you want to restrict users that are not from your app? I get why you might need public read access but restrict reads only from your app but for updates and deletes, appwrite permissions should solve your problem.
Not necessarily I can create my own app, host it locally and point example.com to 127.0.0.1 As far as I know appwrite doesn't require https and therefore has no way of knowing that its a localhost app.
That's what we have said and discussed, but ended creating this other post:
There are few aspects in that matter.
Open access
If for example you've a database that have permission of any
then anyone can create app and spoof as they are you.
But, they won't need to go so far as they can do it using any API explorer like Postman.
Data integrity This is not a security concern per-say but more a data integrity one, to avoid that there are few common solutions
- CORS - for web - blocking access to specific URLs only.
- Package name - for Android and iOS - validating the origin of the package.
The first one CORS is pretty hard to overcome in web browsers, but in mobile there a quick workaround to get over all of that and that is by contacting the API endpoint directly.
So, for example instead of using the appwrite
package for flutter projects the spoofer can use the http
library and make direct calls to the REST API. In that way Appwrite won't be able to know where the request came from.
That's true for any BaaS out there including Firebase.
To mitigate this issue Apple created DeviceCheck
and Android created Play integrity
and to use them in Firebase for example you can use the https://firebase.google.com/docs/app-check solution, as it ain't easy to provide out-of-the-box solution for that.
As of now Appwrite doesn't support any of the common integrity checks out there but you can track the issues regarding that matter.
Permissionized Any one can use packet analyzer apps like Wireshark to get hold of all the API requests, and as such all web-apps out there using the network tab.
Becuase of that, in general when passing data on the web you should use on of these two approaches
- Allow to all
- Allow by permission
When you're allowing data by permission, then it may be inconveniente when someone uses mocking your app package to get access, but that will help only passing the first barrier nothing more.
Package name and CORS protection in Appwrite mainly meant to be used as general guards and not protecting against attacks, etc. as for that Appwrite has many other code logic guards like the rate limiter
Appwrite does require https though, right?
Correct me if I'm wrong obviously, but https, at least on cloud is enabled
On self-hosted, that depends on the setup
Ahh I think it is. I didn't know because it is not needed in localhost and everything I host is in netlify so automatic https so ig I just never noticed π
Hahaha that happened to me as well LMAO
[CLOSED] Appwrite Data Security Issue
Recommended threads
- My account is blocked so please check an...
My account is blocked so please unblock my account because all the apps are closed due to which it is causing a lot of problems
- Deep Linking & Password reset
I am using react native with expo. I want to implement deep link with the url recived via email. So when clicked the link it opens my app. I havent ever used de...
- custom domain with CloudFlare
Hi all, it seems that CloudFlare has blocked cross-domain CNAME link which made my app hostname which is in CloudFlare, unable to create a CNAME pointing to clo...