
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
- Flutter OAuth2 Google Login – Redirect I...
i tried implementing OAuth2 Google Login in my app, and it works fine for the most part, the problem am facing is when i chose a google account to sign in/up wi...
- Cannot use Google Oauth in my Project
I tried to use Appwrite Google Oauth Provider in my app but had some troubles. I receives this error no matter what: error or success: 2025-09-21 18:50:33.845 3...
- Adding "name" column to table creates 2-...
As stated, im adding the "name" column to one table, it adds 4 duplicates. In another table it adds 3 duplicates, and when I delete 1 of them, all duplucates di...
