Security
Jewekle holds receipt-level purchase data. That's sensitive. The architecture is built to make sure only you — and only when authenticated — can read your own data. Here's how.
Transport security
Every connection between the Jewekle app and our backend uses TLS 1.3 with strong cipher suites. We pin certificate validation to standard system roots; we do not allow self-signed certificates in production. Plaintext HTTP is rejected by the API.
At-rest encryption
Your data lives in two places, both encrypted:
- On the server (Supabase): all data is encrypted at rest using AES-256 on encrypted EBS volumes. Database backups inherit the same encryption.
- On your device: authentication tokens and any provider credentials are stored in Apple Keychain (iOS) or Android Keystore via Expo's secure storage. These are hardware-backed when the device supports it.
Per-user data isolation
Every table in our database has Row-Level Security (RLS) policies that filter rows by the authenticated user's ID at the database layer. Even if a bug made the app query "all invoices", PostgreSQL would return only the rows you own. This is enforced by the database engine — not by application code that could be bypassed.
We have an automated test suite that verifies RLS policies actually prevent cross-user reads. The tests run against the same database schema we use in production.
Authentication
Authentication is handled by Supabase Auth:
- Passwords hashed with bcrypt using per-user salts
- JWT-based session tokens with short expiry + refresh tokens
- Refresh tokens stored in iOS Keychain / Android Keystore — never plaintext
- Email verification required before account activation
- Password reset uses one-time links sent to the registered email
Sign-out hygiene
When you sign out, the device is wiped clean — every Zustand store (invoices, corrections, learned rules, budgets, household state, sync queue) is reset, and every namespaced storage key is removed. This prevents a different user signing in on the same device from seeing any trace of the previous session. The design assumption is "shared devices exist; behave accordingly."
Crash reports & analytics
We use Sentry for crash reporting and PostHog for anonymous product analytics. Both are configured to never receive invoice contents, merchant names, or amounts. Crash reports contain only stack traces and device metadata; analytics events contain only the event name and minimal context.
Third-party access
The only third parties with any access to user data are our processors: Supabase (storage), Sentry (crash reports), and PostHog (event analytics). We don't share data with advertisers, data brokers, or any party not strictly necessary to operate the Service. See the Privacy Policy for the full list.
Vulnerability disclosure
If you find a security vulnerability — anything from a real exploit to a "this looks weird" hunch — please report it to security@jewekle.com with the subject "Security disclosure". We commit to:
- Acknowledging your report within 48 hours
- Providing a status update within 7 days
- Fixing critical issues within 30 days of triage
- Crediting researchers who responsibly disclose, if they wish
We don't currently run a paid bug bounty, but if your report materially improves our security we'll send a thank-you note and credit you publicly (with your permission).
What we're working on
Security is a moving target. Items on our roadmap:
- Two-factor authentication (TOTP) for accounts
- Automated security scanning in CI
- SOC 2 Type II readiness as we scale
- Independent penetration testing before public launch
Questions?
Reach our security team — we take every report seriously.