Security at TradersFlow

Security is treated as an engineering discipline, not a checkbox. Every change to TradersFlow goes through code review with security considerations. We follow the principle of least privilege across our codebase and infrastructure.

• Secure-by-default configuration for every new service and table.
• Automated dependency scanning to catch vulnerable libraries early.
• Secrets stored in a managed vault — never in code, never in logs.
• Role-based access controls on all internal admin tooling.

TradersFlow runs on hardened cloud infrastructure (Supabase on AWS) in EU regions, with Cloudflare in front for DNS, edge networking and DDoS protection. Our hosting partners maintain SOC 2 Type II and ISO 27001 certifications and operate physically secured data centres with 24/7 monitoring.

Application traffic is served over HTTPS only. Insecure HTTP requests are automatically upgraded. We enforce HSTS, modern TLS ciphers, and a strict Content Security Policy.

All customer data is encrypted at rest using AES-256 and in transit using TLS 1.3. Database access is locked down with row-level security so a query for one user can never return another user's data — even in the event of an application bug.

Uploaded photos and documents are stored in isolated, per-account buckets with signed URLs that expire automatically. Passwords are never stored in plain text — only as salted, modern cryptographic hashes.

Every request to a protected resource is checked on the server against the authenticated session — we never rely on hiding UI as a security measure. Database row-level security and server-side permission checks both have to pass before any read or write is allowed.

Optional sign-in with Google and Apple delegates authentication to providers with strong, mature security models, including support for hardware-backed multi-factor authentication. Suspicious sign-in attempts trigger rate limiting and (where appropriate) automatic lockout. You can sign out of all devices from your account settings at any time.

Subscription billing is powered by Stripe, a PCI-DSS Level 1 certified payment processor. Card details are entered directly into Stripe's hosted checkout sessions — they never touch our servers. We only store a Stripe customer reference and a high-level subscription status.

Subscription state — active, trialing, past-due, cancelled — is reconciled from Stripe via signed webhooks (see next section), so what you see in the app reflects what Stripe holds. Customer-facing invoice payment links you create are also Stripe-hosted, and funds settle directly to your connected account; TradersFlow does not hold customer funds.

TradersFlow processes webhook events from Stripe for subscription, invoice and payment updates. Every incoming webhook is verified against its signing secret before any business logic runs. Unsigned, expired or tampered events are rejected. Processed events are logged so we can reconcile any discrepancy and detect duplicates.

The TradersFlow admin area (used for support, billing operations and platform analytics) is restricted to a small, hardcoded allow-list of TradersFlow owners. Access is enforced server-side on every request — not only in the UI. Non-owners attempting to reach an admin route receive a 403.

Sensitive admin actions — generating a temporary sign-in link, issuing a refund, suspending or reinstating an account, extending a trial, exporting reports — are protected behind explicit confirmation and recorded in the audit log described below.

Administrative actions are written to an immutable audit log that records who did what, against which account, and when. The same approach extends to security-relevant events on your account — sign-ins, password and email changes, subscription state changes and deletions — so we can investigate anything unexpected.

Every transactional email TradersFlow sends — verification, password reset, trial reminders, invoices, payment notices — is logged with its template, recipient, send status and downstream events (delivered, opened, clicked, bounced, complained, unsubscribed). We use these signals to retry failed sends, prevent duplicates, respect suppression lists, and alert ourselves if the overall failure rate exceeds a healthy threshold.

Our systems are monitored 24/7 with automated alerts on errors, latency spikes, failed webhooks, email delivery health and security events. Account activity is logged for fraud prevention and incident review. Our target uptime is 99.9% across calendar quarters.

We have a documented incident response plan covering detection, containment, eradication, recovery and post-incident review. If an incident affects your data, we will notify you without undue delay — and, where GDPR requires, within 72 hours of becoming aware.

If you're a security researcher and have found a vulnerability, we'd like to hear from you. Please email security@tradersflow.co.uk with details and we'll acknowledge within 48 hours.

We commit to: investigating in good faith, keeping you updated, and not taking legal action against researchers who follow this policy and act in good faith. Please don't access data that isn't yours and don't disrupt the Service for other users.

For anything security-related — questions, concerns, vulnerability reports — email security@tradersflow.co.uk.