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
- {"code": 1008, "message": "Invalid Origi...
Nothing has changed in my application or console settings so I'm curious as to what I need to do to fix this. I already have the client registered so I'm not en...
- android platform invaild origina
It happened today suddenly. Our app says invalid origin. And appwrite cloud says every time we tried to add the app to it: "param platformId" is not optional.
- All my apps are not opening now
All my apps are not opening now 200+ apps are not opening plz fast