Skip to content
GLORESEND

Security

Controls we have implemented, and what is still ahead.

GLORESEND holds no security certification today. Implemented controls are listed below and covered by automated tests; they are not a guarantee that the system is free of vulnerabilities.

Identity & access

  • Passwords hashed with argon2id (OWASP parameters); minimum 12 characters.
  • TOTP two-factor authentication with single-use recovery codes; required for Live access requests and Live credentials.
  • Server-side sessions: random 256-bit tokens in HttpOnly, SameSite=Lax, Secure cookies; only a SHA-256 of each token is stored; a new session id on every sign-in and after 2FA.
  • Account lockout after 10 failed attempts, per-IP and per-email rate limits on sign-in, and identical errors for unknown emails and wrong passwords.
  • Role-based access (owner, admin, developer, viewer) enforced on the server for every operation; sensitive actions require recent password confirmation.

API credentials

  • Keys generated from a CSPRNG (~238 bits), shown once, stored only as HMAC-SHA256 with a server-side pepper.
  • Environment encoded in the key prefix and checked before lookup; Sandbox keys never authenticate against Live, and vice versa.
  • Scopes, expiry, rotation with optional grace period, revocation and last-used tracking.
  • Per-key rate limits with standard RateLimit and Retry-After headers. No CORS on the secret-key API.

Application

  • Strict schema validation of every body and query; unknown fields are rejected.
  • Parameterized SQL through the ORM; LIKE wildcards escaped in searches.
  • CSRF defence: Origin checks on every state-changing dashboard request, JSON-only bodies and SameSite cookies.
  • Content-Security-Policy with per-request nonces, frame-ancestors none, HSTS in production, and other security headers.
  • Request bodies limited to 64 KB; generic error responses with request ids, never stack traces.
  • Send Box accepts a path, never a URL, matched against documented endpoints and sent to a fixed internal origin — no arbitrary proxying.
  • Webhook URLs must be HTTPS and resolve to public addresses; the check is repeated at connection time to block DNS rebinding.

Data & money

  • Amounts are integers in minor units with database CHECK constraints against negative balances.
  • Row-level locks for every balance change and an append-only ledger with balance snapshots.
  • Idempotency keys scoped per organization and environment; reuse with a different body is rejected.
  • Webhook signing and 2FA secrets encrypted at rest with AES-256-GCM; full destination account numbers are not persisted.
  • Every organization-owned row carries its organization id and every query filters by it.

Operations

  • Structured JSON logs with redaction of credentials and personal data; request logs store metadata only.
  • Audit events for sign-ins, 2FA changes, key and webhook management, membership changes and Live operations.
  • Production refuses to start without real secrets or with the embedded development database.
  • Live money movement fails closed until an authorized provider adapter is installed and explicitly enabled.

Before production

  • Independent penetration test and code review by a third party.
  • Compliance programmes required by the chosen providers and markets (for example PCI DSS if card data is ever handled, licensing and AML/KYC obligations).
  • Managed secrets (KMS/secret manager) and key rotation procedures for ENCRYPTION_KEY and API_KEY_PEPPER.
  • Shared rate-limit store (e.g. Redis) when running more than one API instance.
  • Centralized monitoring, alerting and on-call; tested backup restores.
  • Email verification and transactional email for invitations and security notifications.

Reporting a vulnerability

A security contact has not been configured for this deployment yet (SECURITY_CONTACT_EMAIL).