Appwrite provides many security features to keep both your Appwrite project and your user's information secure.
Appwrite handles the persistence of the session in a consistent way across SDKs. After authenticating with an SDK, the SDK will persist the session so that the user will not need to log in again the next time they open the app. The mechanism for persistence depends on the SDK.
Only keep user sessions active as long as needed and maintain exactly one instance of the Client SDK in your app to avoid conflicting session data.
|Web||Uses a secure session cookie and falls back to local storage when a session cookie is not available.|
|Flutter||Uses a session cookie stored in Application Documents through the path_provider package.|
|Apple||Uses a session cookie stored in UserDefaults.|
|Android||Uses a session cookie stored in SharedPreferences.|
In Appwrite versions 1.2 and above, you can limit the number of active sessions created per user to prevent the accumulation of unused but active sessions. New sessions created by the same user past the session limit delete the oldest session.
You can change the session limit in the Security tab of the Auth Service in your Appwrite Console. The default session limit is 10 with a maximum configurable limit of 100.
Security is very important to protect users' data and privacy. Appwrite uses a permissions model coupled with user sessions to ensure users need correct permissions to access resources. With all Appwrite services, including databases and storage, access is granted at the collection, bucket, document, or file level. These permissions are enforced for client SDKs and server SDKs when using JWT, but are ignored when using a server SDK with an API key.
Password history prevents users from reusing recent passwords. This protects user accounts from security risks by enforcing a new password every time it's changed.
Password history can be enabled in the Auth service's Security tab on the Appwrite Console. You can choose how many previous passwords to remember up to a maximum of 20 and block users from reusing them.
Password dictionary protects users from using bad passwords. It compares the user's password to the 10,000 most common passwords and throws an error if there's a match. Together with rate limits, password dictionary will significantly reduce the chance of a malicious actor from guessing user passwords.
Password dictionary can be enabled in the Auth service's Security tab on the Appwrite Console.
Encourage passwords that are hard to guess by disallowing users to pick passwords that contain personal data. Personal data includes the user's name, email, and phone number.
Disallowing personal data can be enabled in the Auth service's Security tab on the Appwrite Console.