ProfitBinder

Security and data boundaries

The controls protecting ProfitBinder’s private-beta service and seller data.

Tenant isolation

Every customer table uses explicit grants and ownership-based Row Level Security. Account authorization is derived from server-controlled ownership and application metadata, never user-editable metadata. Connected negative tests prove one account cannot read or alter another account's rows.

Authentication

Supabase email and password authentication supports optional customer TOTP MFA. After a customer enrolls a verified factor, the database and authenticated billing functions require an AAL2 session. Owner-controlled services use MFA where the provider supports it. Publishable browser keys never receive service-role privileges.

Imports

Raw CSV data is parsed locally. Buyer-identifying fields are removed in the browser. Sanitized rows are staged in idempotent batches and committed through one quota-aware transaction. Validation, quota, or retry failure cannot create a partial import. Abandoned staging expires after 24 hours.

Telemetry and backups

Sentry session replay is disabled and financial values, buyer information, CSV rows, authentication tokens, and secrets are removed from telemetry. Optional .profitbinder exports use browser-local AES-256-GCM encryption, and the passphrase is never transmitted. Operational database backups are encrypted before off-site storage and have a tested isolated restore path.

Responsible reporting

If you believe you found a security or privacy problem, email security@profitbinder.com. Include the affected page, what happened, and safe reproduction steps. Do not include passwords, authentication codes, private keys, raw buyer data, or other people's personal information.

Current status

These controls are implemented and tested for the current private beta. ProfitBinder does not claim public-production readiness until billing production approval, legal review, real-data validation, beta evidence, and final release checks are complete.