Security at Open Folio Pro

Compliance Frameworks

Open Folio Pro maps its security program to practical Australian and international control frameworks, with controls reviewed as the product and threat model evolve.

Data Security

Open Folio Pro treats financial data as the most sensitive class of personal information. The controls below cover the full data lifecycle — from ingestion through to deletion — and are reviewed on every significant feature change.

Data Residency & Infrastructure

Encryption

• At rest: AES-256-GCM via AWS EBS volume encryption on all Supabase compute and storage volumes
• In transit: TLS 1.3 enforced between browser → Vercel → Supabase; TLS 1.2 minimum on all other hops
• Database connections: SSL required on all Supabase pooler connections — no plaintext DB access
• Broker API keys: stored as encrypted text columns in Postgres; application layer never logs key values
• Backup encryption: point-in-time recovery snapshots encrypted with Supabase-managed KMS keys; key material not accessible to application layer

Row-Level Security (RLS) Implementation

Every user-facing table enforces RLS at the database engine level. Even if application code fails to filter by user, the database engine rejects cross-user reads and writes.

RLS policies use Supabase's auth.uid() function, enforced at the database engine level. Every table requires the requesting JWT's user identity to match the row owner — application code cannot override this.

• RLS enabled on user-facing tables; verified during database policy review
• auth.uid() resolved by Supabase JWT middleware — cannot be spoofed by application code
• Service role is restricted to trusted server-side workflows and never exposed to client code or stored in browser

Data Classification & Handling

Backup & Recovery

• Automated point-in-time recovery enabled — 7-day recovery window on Supabase Pro plan
• Daily logical backups exported to AWS S3 ap-southeast-2 with AES-256 encryption
• Recovery objective (RPO): ≤ 24 hours for logical backup; ≤ 5 minutes for PITR
• Recovery time objective (RTO): target < 2 hours for full restore from PITR
• Backup restoration tested quarterly — restore to isolated Supabase project, validate row counts and RLS policies
• No backup data stored outside Australian jurisdiction

Data Lifecycle & Deletion

• Account deletion: triggers cascade delete across all user_id-linked tables
• Deletion is hard delete — no soft-delete / tombstone pattern for financial records
• Broker API keys removed from database immediately on connection removal; not retained in backups after next PITR window expires (≤ 7 days)
• Email address retained in Supabase Auth for 30 days post-deletion for abuse prevention, then permanently purged
• Users can request immediate full deletion via support — completed within 30 days per Australian Privacy Act APP 12

Audit Logging

• Supabase database audit log records DDL changes with timestamp, role, and statement
• Application-level audit: import batches tracked in import_batches table — immutable once written
• Authentication events logged by Supabase Auth with IP and user agent
• Admin access to Supabase dashboard requires individual named accounts — no shared credentials; access reviewed quarterly
• Logs retained 30 days at platform level; critical auth events retained 12 months in application audit table

Privacy Act & APP Compliance

Open Folio Pro is subject to the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles. Key controls:

Third-Party Data Processors

Security Testing Cadence

• Dependency vulnerability scan: every pull request via npm audit + Snyk — blocks merge on high/critical CVEs
• Static analysis: every pull request
• Secret scanning: every commit via pre-commit hook
• Manual security review: each new API route and database migration reviewed against OWASP API Top 10 before merge
• Annual third-party penetration test; scope covers authentication, RLS bypass, API enumeration, and credential handling
• OWASP Top 10 self-assessment: reviewed on each major feature release

Network Security

Perimeter

• All traffic via Vercel Edge Network with DDoS mitigation at CDN layer
• HTTPS enforced; HTTP → HTTPS redirect at edge
• No public-facing SSH; infrastructure managed via Supabase and Vercel control planes
• CSP, X-Frame-Options, X-Content-Type-Options, and HSTS headers on all responses

API Rate Limiting

• Public endpoints rate-limited at Vercel edge
• Authenticated routes scoped per-user via JWT validation on every request
• No batch endpoints usable for enumeration

Supabase Network Controls

• Supabase project restricts direct DB connections to internal pooler only
• PostgREST API requires valid JWT from Supabase Auth — anonymous calls rejected
• Database auditing enabled for DDL changes

Identity & Access Management

User Authentication

• Authentication via Supabase Auth (OAuth 2.0 / PKCE for magic link + social login)
• Short-lived JWTs (1 hour) with automatic refresh token rotation
• No passwords stored — passwordless magic link or OAuth only
• MFA: Supabase Auth TOTP available (user-optional, enforced for admin accounts)

Least Privilege

• Application service role has no DDL permissions — schema changes via migration tooling only
• Admin access restricted to named individuals; audited quarterly
• Broker API keys requested with minimal permissions (read-only where supported)

Secrets Management

• All secrets stored as Vercel environment variables — never committed to source control
• .env files git-ignored; pre-commit hook blocks accidental secret commits
• Secret rotation procedure documented in internal runbook

Transport Security

TLS Everywhere

• TLS 1.2 minimum; TLS 1.3 preferred — negotiated via Vercel Edge
• HSTS with max-age=31536000; includeSubDomains — prevents protocol downgrade
• Certificate management automated via Let's Encrypt / Vercel-managed certs

API Communication

• All external API calls made server-side only — keys never exposed to browser
• Outbound requests use HTTPS; certificate validation enforced
• Broker sync operations authenticated per-user — no shared service credentials

Email Delivery

• Transactional email via Resend (DKIM + SPF + DMARC on sending domain)
• No sensitive financial data in email bodies — links only
• Unsubscribe honoured within 10 business days per Australian Spam Act 2003

Threat Model

OpenFolio Pro's threat model is mapped to the MITRE ATT&CK framework (Enterprise v14). The table below lists the most relevant adversary tactics for a fintech SaaS, and the primary controls that address each.

This mapping is reviewed when new features are added. Techniques not listed are out of scope for the current threat model (e.g. supply-chain compromise, physical access) and are documented separately in the internal risk register.

Incident Response

Internal incident response runbook aligned to NIST SP 800-61. Contact security@openfoliopro.com.au for vulnerabilities. Confirmed breaches affecting user data reported to OAIC within 30 days per Notifiable Data Breaches scheme.

Responsible Disclosure

Security researchers invited to report findings to security@openfoliopro.com.au. Acknowledge within 3 business days, resolve critical issues within 30 days. No legal action against good-faith researchers.