The flutter_secure_storage package is a wrapper, so security depends on the platform behind it. iOS and macOS use Keychain. Android uses an AES key wrapped by RSA by default, or Keystore with biometrics. Linux needs a keyring service. Web is experimental. Test each target you ship.
iOS and macOS
Data goes in the Keychain. The accessibility option controls when values can be read, with choices such as first unlock and unlocked, where unlocked is the default. The package docs warn about a trap: when you use App Groups, you must add the group to keychain access groups in both debug and release entitlements, or writes appear to succeed and are never saved.
Android
The default options wrap an AES-GCM storage key with RSA OAEP, with no biometrics. The package also offers a biometric mode that keeps an AES-GCM key in the Android KeyStore. Enforcing biometrics has API level requirements, and the docs list API 28 and above for enforcement, with strong biometric only needing API 30 or higher. The docs mark the older encrypted shared preferences option as no longer recommended. The minimum SDK is 23.
Backups are a classic failure. The docs say Google Drive auto backup can restore data that cannot be decrypted, causing key unwrap errors, and suggest disabling backup for the app or excluding the preference files the package uses. Test restore on a new device.
Linux, Windows and web
On Linux, the package uses libsecret and needs a keyring service such as gnome-keyring or KWallet. If there is none, behavior is poor, so detect it and handle failure. Windows uses platform specific mechanisms the docs do not name. Web storage is experimental, built on WebCrypto with values in local storage, and it needs HTTPS.
What it will not do
Secure storage helps when someone reads files from the device, or a backup. It does not help against malware running in your app's context, a rooted device, or a stolen token that the server keeps accepting. Pair it with short lived tokens, revocation on the server and sensible session limits.
Checklist
- Choose the accessibility level that matches how the app uses the data.
- Turn off or exclude Android auto backup for the storage files.
- Test Linux without a keyring and web in your supported browsers.
- Keep only what you must: a refresh token, not a password.
- Wipe on logout and on account change.
Quick check
Should I keep an API key in secure storage?
If the key is a shared app secret, no. Anyone with the app can obtain it at runtime. Use secure storage for per user credentials, and keep shared keys on a server.
Sources
Last reviewed: 19 October 2026.
