Available today
- Authentication Passwords are hashed with bcrypt. Sessions use secure, HTTP-only, same-site cookies in production. Email verification and password-reset links are hashed, expiring, and single-use.
- Role and tenant enforcement Server routes check workspace membership and role; identifiers from another workspace are not returned.
- SSRF defences Alertira accepts HTTP(S) on standard ports, resolves targets before connection, pins the chosen public IP, checks the connected address, manually revalidates redirects, blocks HTTPS downgrade, and caps time and response bytes.
- Integration secrets Provider tokens, signing secrets, and webhook URLs are authenticated-encrypted with AES-256-GCM under a dedicated server key, omitted from API responses and audit metadata, and erased from the active row when removed.
- Synthetic-data policy Password, payment, file, bank, and consent fields are refused. Configured values are shown as [REDACTED] in check results and incident evidence.
- Incident integrity Database locks, confirmation thresholds, one-open-incident constraints, and idempotent email/Slack delivery keys reduce duplicate alerts and inconsistent recovery.
- Billing integrity Product identifiers are chosen server-side. Subscription access changes only after signed, deduplicated Dodo webhooks.
Provider-dependent controls
Cloudflare Turnstile adds bot challenges when both keys and production enablement are configured. Cloudflare R2 holds private evidence when bucket credentials exist; missing storage never changes check status. Resend accepts lifecycle and incident messages for delivery; when its signed webhook is configured, Alertira records mail-server delivery, delay, bounce, suppression, complaint, and provider-failure states separately. Sentry receives scrubbed diagnostics when configured. PostHog receives curated pseudonymous server events only and no raw target, form, or evidence data.
Browser monitoring boundary
Standard server-side HTML form monitoring is the paid-beta path. JavaScript-heavy browser journeys are Planned and are rejected by the paid-beta API. They will not be enabled until Alertira has a hardened disposable sandbox, deny-by-default operating-system egress, and an independently reviewed browser policy.
Encryption, access, and retention
HTTPS protects browser and provider API traffic. Integration secrets use a separate authenticated-encryption key shared only by the web and worker services; losing that key makes existing connections unrecoverable, so it must be backed up securely. Railway private networking is used for the production database; public database connections require a verified certificate authority. Private R2 objects are fetched only after workspace authorisation. The worker removes evidence after 30 days and deletes plan-expired check history; an R2 lifecycle rule is recommended as a second deletion control. We do not claim certifications, a formal SLA, regional residency, or unverified encryption properties.
Report a vulnerability
Please send a concise reproduction and impact assessment to security@alertira.com. Do not access other customers’ data, disrupt service, run denial-of-service tests, or expose findings publicly before coordination.
Security is shared: customers must configure only authorised targets, use synthetic values, protect accounts, and keep target systems and integrations secure.