Security

Call Alert can place phone calls and send text messages, so the controls that stop it being misused matter as much as the controls that stop data being stolen. Here's what's in place today.

Phone verification is the primary anti-spam control

Every destination number - not just your account's default - must be verified with an OTP in the console before it can receive a call or SMS. An integration's API key can never add or verify a number itself, so a leaked key is still constrained to destinations you've personally confirmed.

Optional two-factor authentication

Enable TOTP-based MFA on your account login as a second, independent layer on top of phone verification.

Destination-country allowlisting

Countries we haven't reviewed for reliable, compliant delivery are disabled by default, rather than silently allowed.

API keys are hashed, never stored in plain text

Keys are shown once at creation and stored as a hash - if our database were ever exposed, the keys themselves wouldn't be recoverable from it.

Signed callbacks

Inbound callbacks from our voice/SMS provider and our payment provider are verified against their cryptographic signatures before being trusted.

Secrets are never hardcoded

Provider credentials and API secrets live in a managed secrets store, not in source control or plain environment files in production.

Encryption in transit

All console, API, and webhook traffic is served over TLS.

Found a security issue? Please report it to security@callalert.example rather than filing a public issue - see the Contact page for details.