Security & responsible disclosure

Last updated 2026-05-05

Reporting a vulnerability

Email security@solotrade.com.au (or support@solotrade.com.au as a non-urgent backup). Include enough detail for us to reproduce the issue. We aim to acknowledge within 2 business days and resolve critical issues within 14 days.

Machine-readable contact info: /.well-known/security.txt (RFC 9116).

What's in scope

Authentication and authorisation flaws on the SoloTrade app, our Supabase project, and our Edge Functions
Data exposure (PII, business records, receipt photos, OCR output)
Privilege escalation
Injection vulnerabilities
Cryptography misuse - we use AES-256-GCM for receipt photo encryption with per-user DEKs in Supabase Vault
Issues in our open-source build process (signing, dependency lock files)

What's out of scope

Vulnerabilities in our sub-processors (Supabase, RevenueCat, Resend, Sentry, Google Cloud - Document AI / Maps / Drive / Gmail / Play Integrity / ML Kit, Upstash, Netlify, Expo Application Services, Apple App Store, Google Play, Zoho Mail) - please report those directly to the vendor.
Social-engineering attacks against the operator
Theoretical issues without a working proof of concept
Reports based purely on missing security headers (we welcome them, but they don't qualify as a vulnerability)

Our crypto posture (so you know what to attack)

Receipt photos (Mode A): AES-256-GCM, 12-byte IV, 16-byte tag. Per-user DEK held in Supabase Vault, wrapped with the project KEK. The Edge Function decrypts in memory only; the storage object is overwritten with the encrypted bundle.
Receipt photos (Mode B): AES-256-GCM stored in SQLCipher on the user's device. Photo never reaches our servers.
OAuth refresh tokens (Drive, Gmail) and per-user receipt DEKs: wrapped in Supabase Vault using the project KEK; never returned to the client; only Edge Functions with service-role can read them.
Database: Supabase managed Postgres in Tokyo (ap-northeast-1) with at-rest encryption (AES-256 by Supabase / AWS).
Transport: TLS 1.2+ enforced by Supabase. HSTS is enabled by Netlify on solotrade.com.au and by Supabase on supabase.co.
RLS: Row Level Security policies on every user-data table; service-role only used inside Edge Functions, never sent to clients.
Auth tokens on device: stored in OS-level secure storage (iOS Keychain / Android Keystore) via expo-secure-store.
Cert pinning: not enforced in v1 (see src/lib/security/certPinning.ts for the v1.1+ plan).
Play Integrity: wired up server-side; required for sensitive Edge Functions in production.
HIBP password protection: enabled via Supabase Auth (rejects sign-up with passwords known to be breached).
Crash reporting (Sentry): PII (email, auth tokens, request bodies, cookies) is stripped client-side in beforeSend before transmission.
Server-side rate limiting (Upstash): per-user token bucket on every Edge Function that processes untrusted input (image redaction, PDF generation, OCR, geocoding).

What we offer in return

SoloTrade is a small operation; we don't run a paid bounty program in v1. What we can offer is a fast, technical response, public acknowledgment (with your consent), and a personal thank-you. If your report leads to a paid product subscription extension, we'll happily comp it.

Acknowledgments

Reporters who choose to be named will appear here. (empty - be the first!)

SoloTrade is operated by SoloTradeOS, ABN 75 640 151 073.