Varuno security
This page describes how Varuno protects your data, in plain language — including the parts that are still limits or open work. We would rather you read an honest list than a reassuring one.
What protects your data
- Encryption at rest. The on-device database is encrypted with AES-256 (SQLite3MultipleCiphers). The 256-bit key is stored per account in the iOS Keychain, separate from the database file.
- Per-account isolation. Every account on a device gets its own database file and key. A second account cannot read the first’s data.
- Encryption in transit. Both of the app’s network connections (the account service and the exchange-rate service) use TLS.
- Account security. Email + password with mandatory verified email, using PKCE for the email deep links. Signed-out users cannot reach any in-app data screens — the authenticated part of the app is not even constructed until sign-in completes.
- App lock. A key-derivation-strengthened passcode, optional Face ID on top, auto-lock, a privacy cover in the app switcher, and re-authentication for dangerous actions. Changing the device’s biometric enrolment deliberately invalidates biometric unlock.
- Server-side access control. The only server-side personal data (your profile row: name, country, base currency) is protected by row-level security, enabled and forced in the database migration, restricted to your own account.
- Deletion ordering. Account deletion destroys the local vault key before the database file, so an interruption leaves unreadable ciphertext rather than data.
- No third-party surface. No analytics, ads or crash-reporting SDKs. Document processing (OCR) runs on-device. Import workspaces are cleaned up when sessions end, with a 12-hour sweep for abandoned ones.
Current limits and open items — the honest list
- Backup exports are not encrypted. They are readable JSON, disclosed prominently at export time. Anyone who obtains the file can read your financial history. Treat backup files as sensitive documents.
- There is no web version, partly for security. Database encryption is not available in the browser, so a web build would not meet the app’s own bar. This is a recorded, deliberate deferral.
- The email deep link uses a custom URL scheme, which another app on a device could theoretically claim. The sign-in flow uses PKCE, which prevents a claiming app from completing authentication with intercepted links. Universal links (which remove the issue) are planned but depend on release signing.
- Row-level security tests exist but have not yet been executed against a live database (the test environment requires infrastructure not yet in place). The policies themselves are defined and forced in the migration — we claim “policy-enforced”, not “test-verified”.
- Some security-relevant flows are code-complete but not yet device-verified in the current QA cycle: biometric unlock, notification delivery, the payslip pipeline end-to-end, and account deletion end-to-end. They are being verified as part of TestFlight QA.
- “Deleted” means removed and unlinked. Varuno does not claim physical erasure of flash storage, because wear-levelling makes that promise unhonest for any app.
Reporting a security issue
Please report suspected vulnerabilities privately. A dedicated security contact is being set up ([SECURITY_EMAIL_REQUIRED]); until then, use the contact form with the “Privacy request” type, and do not include other people’s data or working exploits.