Security

Sendoka carries transactional email and SMS for other people's products, so the security of accounts, credentials, and message data is the product. This page describes the measures in the platform today — it lists what is built, not what is planned.

Account security

Passwords are hashed with bcrypt. At registration and password reset, candidate passwords are checked against the Have I Been Pwned breach corpus using its k-anonymity range API — only the first five characters of a SHA-1 hash ever leave our infrastructure, and the match happens locally.

Two-factor authentication uses authenticator apps (TOTP). Organization owners can mandate 2FA for every member; the mandate is enforced in request middleware, and a member who has not enrolled can reach nothing but the enrollment flow until they do.

Sessions are versioned. A password reset, 2FA recovery, or "sign out other sessions" bumps the account's session version, and live sessions are re-validated against it, so revoked sessions stop working within about thirty seconds.

API credentials

API keys are shown once at creation and stored as a SHA-256 hash plus the last four characters. The full key is never persisted and cannot be retrieved later. Keys support expiry dates, scope restrictions, per-key rate limits, and IP (CIDR) allowlists, and suspending an organization cuts off all of its keys at once.

Tamper-evident audit log

Sensitive dashboard and API actions are recorded in an audit log. Each row is signed with an HMAC (SHA-256) under a secret held only in the application environment, so after-the-fact modification of a recorded row can be detected without trusting the database it sits in.

Webhooks

Webhook deliveries are signed with HMAC-SHA-256, including a timestamped signature scheme that lets receivers reject replayed payloads. Signing secrets rotate with zero downtime: during a rotation grace window, deliveries carry signatures under both the old and the new secret. See the verification guide.

Tracking links

Open and click tracking URLs are HMAC-signed. The redirect endpoint verifies the signature and refuses tampered destinations, so a tracking link can only send a recipient where the original message pointed.

In transit

All traffic is served over TLS. HSTS is set with a two-year max-age, includeSubDomains, and preload, and responses carry a Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a strict Referrer-Policy.

Infrastructure

Sendoka runs on Vercel. Data lives in Neon (Postgres) and Upstash (Redis); email is delivered through AWS SES and SMS through AWS End User Messaging. Neon and AWS apply provider-managed encryption at rest as their platform default. Payments are processed by Stripe — card details go to Stripe directly and are never stored by Sendoka.

Data processing

Our Data Processing Agreement covers the scope of processing and subprocessors. Per-user data export and erasure are self-serve from Settings → Security.

Reporting a vulnerability

If you believe you have found a security issue in Sendoka, email security@sendoka.com with enough detail to reproduce it. We read every report and will respond. Please give us a reasonable window to remediate before disclosing publicly, and do not access data that is not yours. We do not currently run a paid bug bounty program.

This contact is also published machine-readably at /.well-known/security.txt.