Database security controls

Current control model

Control	Purpose	Review position
Managed PostgreSQL	Separates infrastructure operation from application data design	Supabase operates the platform; FinTrack owns schema and data controls
Managed authentication	Establishes signed application identities and sessions	Implemented
Database grants	Controls whether an API role can reach a data object or operation	Implemented; least-privilege review remains continuous
Row-level security	Restricts rows available to ordinary API identities	Enabled on all reviewed public tables at the current read-only review point
Policies and trusted operations	Enforce tenant, role, hierarchy, ownership, and workflow rules	Implemented across application domains; individual correctness is not universally certified
Constraints and transactions	Protect relationships and multi-record invariants	Used across the system of record
Migration change control	Makes schema and policy changes reviewable and repeatable	Established as an operator-controlled process
Security advisor	Detects configuration risks and database-security smells	Current review contains unresolved warnings and informational findings

Required security practices

1. Keep all exposed tables protected by row-level security and explicit grants.
2. Test anonymous, authenticated, cross-tenant, ownership, hierarchy, and privileged cases.
3. Restrict elevated functions, set safe execution context, and validate the caller in the body.
4. Keep privileged keys outside public clients.
5. Review security-advisor findings to remediation or documented risk acceptance.
6. Verify migrations before and after controlled deployment, with rollback or recovery guidance.
7. Retain audit evidence for sensitive access and administrative changes.

Enforcement-layer test matrix

Test identity	Read case	Write case	Required result
Anonymous	Publicly classified content only	No protected mutation	Protected records and operations are denied without a signed identity
Ordinary tenant user	Records within assigned tenant, hierarchy, ownership, or mapped scope	Only permitted workflow fields and transitions	Cross-tenant, peer-restricted, and privileged data remain inaccessible
Management user	Expanded subordinate or assigned scope	Management operations allowed only within current authority	Role level does not bypass tenant or target restrictions
Privileged application user	Approved administrative scope	Explicit administrative operations	Every privileged operation validates actor, target, purpose, and current state
Trusted workload	Only data required for the defined function	Bounded service transaction	Caller or event authenticity, tenant, input, replay, and idempotency checks pass before elevated access
Database administrator	Operational administration under authorization	Controlled maintenance or recovery	Access is named, recorded, reviewed, and excluded from ordinary application use

For each exposed record domain, the review records reachable roles, grants, row-policy predicates, write checks, privileged operations, storage linkage, and negative cases. The test set uses direct API access rather than relying on hidden UI routes. Changes to tenant, hierarchy, ownership, menu, or reporting logic trigger review of both application behavior and database enforcement.

Migration security gate

Gate	Required decision
Precondition	Confirm expected schema version, object existence, data shape, extension dependency, and backup or recovery requirement
Expansion	Add compatible objects or nullable fields before depending on them; avoid breaking active clients during rollout
Data movement	Bound the affected rows, batch long work, preserve attribution, and make restart or reconciliation behavior explicit
Access	Define grants, row-level security, write checks, function execution rights, search path, and ownership before exposure
Verification	Execute anonymous, tenant, cross-tenant, hierarchy, ownership, privileged, constraint, and performance checks
Deployment	Record operator, approved migration set, start/end time, provider result, and application compatibility
Failure	Stop dependent rollout, preserve error and partial-state evidence, and use the approved forward correction or provider recovery path
Closure	Retain post-deployment catalog state, security-advisor review, critical query result, and business-owner confirmation where required

Destructive or privilege-expanding database work is not executed through an undocumented console change. Emergency correction still produces a reviewable migration and an operator-controlled deployment record so the authoritative schema can be reconstructed.

Current limitations

The point-in-time advisor review identified unresolved function hardening, execution-access, authentication-protection, and policy-coverage findings. Object names and counts are omitted from this public summary. The presence of row-level security does not prove that every policy is correct, and tables with no policy intentionally deny ordinary access but still require documented ownership.

• Supabase Data API security
• Supabase row-level security
• Supabase database linter