mangocontact

Security.

The strongest protection for your data is not keeping it. That's our starting point.

The model in one paragraph

mangocontact is built around a simple idea: a live sharing session should behave like the phone call it accompanies — it exists while it's happening, then it's gone. Contact details you share live are held encrypted in server memory only, never written to disk, and destroyed when the session ends. The only stored contact data anywhere in the product is what an account holder explicitly saves, and that is encrypted at rest.

Encryption in flight

  • All traffic is served over HTTPS with HTTP Strict Transport Security (HSTS), so browsers refuse to connect insecurely.
  • Live session updates travel over secure WebSocket connections on the same TLS layer.
  • Security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) restrict what can load on and around our pages.

Encryption in memory — live sessions

  • Session contents are encrypted with AES-256-GCM the moment they arrive, and only the encrypted snapshot is held in working memory.
  • Encryption keys are derived per session and per state — they are not stored alongside the data.
  • Nothing is written to a database, log file, backup, or disk. Memory is configured with no persistence, so nothing survives a restart.
  • Sessions self-destruct: on your command, at the timer, after inactivity, or after 3 wrong emoji attempts. See the data policy for the exact lifecycle.

Encryption at rest — Mango Cards and Contacts

  • If you create an account and save a Mango Card or a collected contact, every personal field is encrypted with AES-256-GCM before it reaches the database. Only non-identifying fields (a card label, a share code) are stored in plain text.
  • The encryption key lives in server configuration, not in the database — stored rows are unreadable on their own.
  • Sharing a card live copies its data into a normal anonymous session; the live session never reads from or writes to the database.

Verifying the right person gets your info

  • A session is unlocked with a random 6-digit code plus an emoji you confirm out loud — a human second factor that a guessed code alone can't pass.
  • Three wrong emoji attempts destroy the session.
  • Code-guessing is rate-limited per IP, on top of a general rate-limit floor across the whole API.

Accounts

  • Sign-in is handled by Clerk, a dedicated authentication provider. We never see or store your password.
  • Dashboard sessions use secure, same-site cookies scoped to our domain.

What an attacker could get

Covered honestly in our data policy: encrypted in-memory snapshots for sessions currently live, nothing at all for past sessions, and AES-256-GCM ciphertext for stored cards — without the key that isn't kept in the database.

Reporting a vulnerability

If you believe you've found a security issue, please email contact@mangocontact.com with enough detail to reproduce it. We read every report. Please don't test against other people's live sessions — anonymous sessions mean we can't tell researchers from attackers.

Read the full data policy →