MSProspector handles sales prospecting data and integrations with third-party CRMs, accounting tools, and payment systems. We take that responsibility seriously. This page explains, in plain English, how we protect your data and what controls are in place.
Encryption in transit
Every connection to MSProspector — from your browser, from our background workers, and from third-party webhooks — runs over TLS 1.2 or higher. HTTPS is enforced at the edge and HTTP requests are upgraded automatically. The site is served with Strict-Transport-Security so browsers refuse to fall back to plaintext, and we are on the HSTS preload list.
Encryption at rest
All application data is stored in Postgres on Supabase, which encrypts the underlying volumes at rest. On top of that, any third-party credentials we hold on your behalf — your GoHighLevel API key, your QuickBooks Online refresh token — are encrypted application-side with AES-GCM-256 before they ever touch the database. Each ciphertext is bound to its owning user via authenticated additional data (AAD), so a stolen master key alone cannot be used to decrypt rows out of context.
Authentication
We use Supabase Auth with passwordless magic-link / OTP sign-in. We never store, see, or transmit your password — because there isn't one. Sessions are carried in HttpOnly, Secure, SameSite cookies that JavaScript on the page cannot read.
Authorization
Every user-owned table in our database is protected by Postgres Row-Level Security policies. The policies are enforced inside the database itself, on top of any application-level checks, so even a bug in our API code cannot let you read or modify another user's reports, credits, integrations, or feedback. Service-role access is restricted to specific server-side workflows (Stripe webhooks, Inngest background jobs, scheduled cleanup).
Payments
All payments are processed by Stripe. We do not see, store, or transmit credit card numbers, CVV values, or full bank account numbers — they go directly from your browser to Stripe's PCI-DSS Level 1 environment. We only persist opaque Stripe customer and subscription identifiers needed to apply credits and offer self-service billing via Stripe's Customer Portal.
Hosting & infrastructure
The application runs on Vercel (SOC 2 Type II, ISO 27001) and our database lives on Supabase (SOC 2 Type II). Background jobs run on Inngest. Each layer enforces its own access controls and audit logging; we use the principle of least privilege between services.
Backups & retention
Supabase takes daily encrypted snapshots of our Postgres database with a 7-day retention window. We can restore from any snapshot inside that window. Stripe and Inngest each retain their own event histories independently, which gives us a second source of truth for billing and background-job state.
Observability & error monitoring
We use Sentry to capture uncaught errors, with PII scrubbing enabled at the Sentry SDK layer so that email addresses, authentication tokens, and request bodies are stripped before an error report leaves our servers. Logs are retained only as long as needed to triage issues.
Browser-side hardening
The application sets a strict Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a tight Permissions-Policy, and a strict-origin Referrer-Policy. These headers reduce the impact of any XSS, clickjacking, or data-exfiltration attempt.
Reporting a vulnerability
If you believe you've found a security issue, please email security@marketopia.com with a description and reproduction steps. We'll acknowledge within two business days and keep you updated as we triage and fix. A PGP key for encrypted reports is available on request — reply to our acknowledgment email and we'll send you the current key fingerprint and public block.
Have a vendor-security questionnaire we should fill out, or want to talk through specific controls before signing? Email the same address and we'll route it to the right person.