TryMellon

Security

Security

This page summarizes the security model of WebAuthn/Passkeys in the context of the TreyMellon SDK 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 only stores 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 leak.

The TryMellon API and SDK follow the WebAuthn spec. The SDK does not perform cryptographic operations beyond what the browser’s WebAuthn API requires.

CSP (Content Security Policy)

If you use a strict CSP, allow the following so the SDK and browser can run WebAuthn:

  • script-src: Allow the domain that serves the TryMellon SDK (e.g. your own origin if you bundle it, or the CDN if you load it from there). Allow 'wasm-unsafe-eval' only if the SDK or a dependency uses WebAssembly.
  • frame-src (if applicable): If the SDK or payment/identity flows use iframes, allow the required origins.

Example (adjust for your setup):

Content-Security-Policy: script-src 'self'; frame-src 'self';

SRI (Subresource Integrity)

If you load the SDK from a CDN, use SRI to ensure the script has not been tampered with. Generate the integrity hash when you pin a specific version and include it in the script tag:

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

What the SDK does not do

  • No cryptography beyond WebAuthn: The SDK does not implement custom crypto. It uses the browser’s Credential Management and WebAuthn APIs.
  • No secret storage: The SDK does not store API keys or secrets in the browser in a way that would be safe for backend use. The session token is meant to be sent to your backend once and then replaced by your own session (e.g. cookie).
  • No PII in logs: Avoid logging full session tokens or credentials. The SDK is designed to work without exposing sensitive data in client-side logs.

Best practices

  1. Always validate the session token on your backend before granting access.
  2. Use HTTPS in production.
  3. Prefer httpOnly, Secure, SameSite cookies for session storage.
  4. Pin the SDK version and use SRI when loading from a CDN.