Encryption in transit and at rest
Encryption boundaries
| Data state | Control summary | Responsibility |
|---|---|---|
| Browser to Cloudflare | Public application delivery uses HTTPS/TLS | Cloudflare operates TLS; FinTrack configures domains and policy |
| Browser or server to Supabase | Managed APIs and database services use encrypted transport | Supabase operates service encryption; FinTrack uses secure endpoints and enforces connections |
| Supabase-hosted data | Supabase states that customer data is encrypted at rest and in transit | Supabase operates platform encryption; FinTrack controls data classification and application access |
| Backups | Supabase states backups are encrypted in transit and at rest | Supabase operates backup encryption; FinTrack controls restore authorization and validation |
| External integrations | TLS is required for approved provider connections | Both parties maintain endpoint and certificate security |
| Browser and endpoint | Data exists in memory, browser storage, downloads, screenshots, or device caches according to user activity | Customer endpoint controls and FinTrack minimisation apply |
Application requirements
- Never place privileged keys or service credentials in public browser assets.
- Minimise personal and financial data sent to external providers and diagnostic systems.
- Application-level field or payload encryption is not currently implemented. Managed platform encryption protects stored service data; no application-managed key material exists in this design.
- Treat encryption as one layer: authorization, retention, masking, and secure deletion remain necessary.
- Record key ownership, rotation, revocation, recovery, and incident handling for any application-managed encryption.
Cryptographic boundary model
| Material | Storage and use boundary | Exposure rule | Rotation or recovery consideration |
|---|---|---|---|
| User passwords | Managed identity provider | Application code never stores plaintext password values after submission to the identity service | Password reset, breached-password screening, MFA, and account recovery are identity controls rather than database decryption operations |
| Signed sessions | Managed identity provider and authorised browser session storage | Tokens are sent only to the application origin and managed services over TLS; raw values are excluded from logs | Token lifetime, refresh reuse, revocation, inactivity, and lost-device policy govern residual exposure |
| Publishable client configuration | Browser-delivered build | Identifies the public service but does not grant privileged access by itself | Rotate independently when supported and rely on row, storage, and function authorization |
| Provider and privileged credentials | Provider secret configuration and trusted runtime | Never embedded in public source, generated browser assets, URLs, or client-readable responses | Maintain owner, purpose, dependent workload, last rotation, expiry, and emergency revocation procedure |
| Database and backup encryption keys | Managed provider boundary | FinTrack relies on provider controls and does not receive raw platform keys | Provider assurance and contractual evidence govern custody, rotation, destruction, and recovery |
| Application-level encrypted payloads | Trusted server boundary where partner protocol or data risk requires it | Decryption is limited to the exact authorised workflow and plaintext is excluded from telemetry | Key version, algorithm, authenticated encryption, rotation, backward decryption, and destruction are designed together |
Transport validation covers HTTPS-only delivery, secure managed-service endpoints, certificate errors, mixed content, callback TLS, and browser behavior. Secret validation inspects the production artefact and source history for privileged values. Application encryption validation uses known-answer tests, tamper rejection, key-version migration, failed-key behavior, and recovery without disclosing real key material.
Application-cryptography requirements
Where application-level encryption is approved, the design uses a current authenticated-encryption construction from a maintained cryptographic library. Nonces or initialization vectors are generated according to the construction's uniqueness requirements. Ciphertext carries an explicit version and the minimum metadata required to select the correct key and algorithm. Authentication failure returns an error without exposing partial plaintext or an oracle that distinguishes internal validation steps.
Key custody separates encryption keys from encrypted business data. Production and non-production keys are independent. Access is limited to the trusted workload that performs the approved operation. Rotation creates a new active version, preserves controlled decryption of required historical data, re-encrypts according to an approved migration, revokes the predecessor after verification, and retains recovery evidence. Custom encryption algorithms, hard-coded keys, deterministic encryption of low-entropy values, and reversible masking are not accepted as cryptographic protection.
Limitations
This page describes platform and architectural controls, not a cryptographic certificate or configuration export. Current TLS versions, cipher suites, custom-domain policy, storage-bucket visibility, key-rotation evidence, and application-level encryption coverage require targeted technical validation.