Security

Every customer table in our PostgreSQL database carries a row-level security (RLS) policy scoped to the organization that owns the row. Isolation is enforced by the database itself, not by application code, so a query cannot cross an organization boundary even if an application-layer check is missed. Within an organization, role-based access control and per-project access scopes decide what each team member can see and change, and privileged actions such as role changes, API key creation and admin impersonation are recorded in an audit log.

API keys are stored only as SHA-256 hashes. The plaintext key is shown once at creation and never again — we cannot recover it, and a database dump does not yield usable keys.

Dashboard authentication is handled by Supabase Auth (magic link, email and password, or Google OAuth) with httpOnly session cookies. Programmatic access to the MCP server uses OAuth 2.1 with PKCE and dynamic client registration; tokens are short-lived, scoped to a single organization, and revocable from the dashboard.

The embeddable widget validates the request Origin (falling back to Referer) against the domain registered for that site, and rejects mismatches — a leaked public site key cannot be used to submit feedback from an unrelated domain. The widget runs entirely inside a Shadow DOM, so it neither reads nor is affected by host page styles. Uploads are restricted to PNG, JPEG and GIF, capped at 5MB per file, and public ingest endpoints are rate limited.

Every outbound webhook is signed with HMAC-SHA256 over the exact request body using a per-subscription secret and sent as X-MCPFeedback-Signature. Receivers should recompute it over the raw body and compare in constant time before trusting a payload. Each delivery also carries a unique delivery id you can use as an idempotency key. Deliveries are queued through an outbox with bounded retries, so a receiver outage never silently drops events.

Data is encrypted in transit with TLS and encrypted at rest by Supabase for both the PostgreSQL database and object storage. Screenshots, recordings and replay frames live in access-controlled storage buckets and are served through short-lived signed URLs rather than public links. The production database has managed, encrypted backups with point-in-time recovery. Secrets are held in the deployment platform’s encrypted environment store and are never committed to source control.

Where a customer’s app enables mobile session replay, the developer selects a privacy tier — mask-all, mask-sensitive or mask-none — which determines how much on-screen content is redacted on the device before anything is transmitted.

We process end-user data only as a processor for the site or app owner and never use it to train models or build profiles. Deleting a record removes both the database row and its files in object storage; deleting an organization purges its records from production systems within 30 days. See the Privacy Policy, DPA and subprocessor list for the full picture.

If you believe you have found a vulnerability, email support@mcpfeedback.com with “[Security]” in the subject line. Include the affected endpoint or page, reproduction steps, and any proof-of-concept. We acknowledge reports within 3 business days and aim to give you a remediation timeline within 10.

Please give us a reasonable opportunity to fix an issue before disclosing it publicly, use only accounts you control, and avoid accessing other people’s data, degrading the service, or running automated scanners at volume. We will not pursue legal action against researchers who follow these guidelines. We do not currently run a paid bug bounty, but we credit reporters who want the acknowledgement.