Security

This page covers the WebAuthn security model, TryMellon’s infrastructure and compliance status, and what you need to configure on your side.

WebAuthn security model

• No shared secrets: Passkeys use public-key cryptography. The private key stays on the user’s device; the server stores only the public key.
• Phishing-resistant: Credentials are bound to the origin (your domain). A fake site cannot use them.
• No password reuse: There is no password to steal or reuse.
• No PII required: TryMellon does not require names, emails, or phone numbers. Your external_user_id is whatever opaque identifier you provide.

The TryMellon API and SDK follow the WebAuthn Level 2 spec. The SDK performs no custom cryptography — it delegates all signing and verification to the browser’s built-in WebAuthn API.

Infrastructure

Data in transit: TLS 1.2+ enforced by Cloudflare on all connections to api.trymellonauth.com.

Data at rest: Credentials (public keys only), session tokens, and audit logs are stored in managed Postgres in US East (Virginia). No private keys are ever stored — they never leave the user’s device.

Data residency note

All processing and storage occurs in US East (Virginia, USA) (AWS us-east-1 equivalent). If your application is subject to data residency requirements (e.g. EU GDPR, Argentine PDPA, Brazilian LGPD), evaluate whether US-based storage is compliant for your use case. Contact us if you need an EU-region deployment.

Compliance status

TryMellon is currently in Beta. We are transparent about the current compliance posture:

What we do have:

• WebAuthn Level 2 implementation (phishing-resistant by design)
• Cloudflare DDoS and WAF protection on the API
• Encrypted connections (TLS) on all endpoints
• Audit logs with 90-day retention (see Admin API)
• GDPR data export and deletion endpoints (see Privacy / GDPR)
• No PII stored beyond your external_user_id unless you explicitly pass metadata

Responsible disclosure: Found a security issue? Email [email protected] before public disclosure. We aim to respond within 48 hours.

If your application operates in a regulated sector (fintech, health, B2B enterprise) that requires SOC 2 or ISO 27001, contact us before going to production. We can provide our current security documentation and timeline to certification.

Passkey migration

Passkeys are device-bound by design (WebAuthn spec). The private key never leaves the user’s device, which means:

• TryMellon stores public keys only — we cannot export private keys
• If you migrate to another WebAuthn provider, users must re-enroll their passkeys

What migration looks like in practice:

1. Deploy your new provider alongside TryMellon
2. On next login, prompt users to register a new passkey with the new provider
3. Because TryMellon is additive (it does not replace your session layer), the transition is a frontend change in how you call the WebAuthn ceremony

The TryMellon SDK is thin by design — switching to another provider means swapping the SDK, not rearchitecting your auth system.

CSP (Content Security Policy)

If you use a strict CSP, allow the following:

• script-src: The domain serving the TryMellon SDK (your bundle origin or CDN).
• connect-src: https://api.trymellonauth.com for SDK API calls.

Example:

Content-Security-Policy: script-src 'self'; connect-src 'self' https://api.trymellonauth.com;

SRI (Subresource Integrity)

If you load the SDK from a CDN, use SRI to ensure the script has not been tampered with. Pin a specific version and include the integrity hash:

<script
  src="https://cdn.example.com/trymellon/v2.3.6/sdk.js"
  integrity="sha384-..."
  crossorigin="anonymous"
></script>

What the SDK does not do

• No custom crypto: The SDK uses the browser’s native WebAuthn API exclusively.
• No secret storage: The publishableKey is safe for the browser. Never put your client_secret in frontend code.
• No PII in logs: The SDK does not log session tokens or credential IDs.

Best practices

1. Validate the session token on your backend before granting access — see Backend validation.
2. Use HTTPS in production (required for WebAuthn).
3. Store your own session in an httpOnly, Secure, SameSite=Strict cookie.
4. Revoke passkeys when a user reports a lost device — see Admin API → Revoke credential.
5. Use audit logs to detect anomalous auth patterns — see Admin API → Audit Logs.
6. Pin the SDK version and use SRI when loading from a CDN.