Security — Kolvera

TL;DR

Bcrypt password hashing. TOTP two-factor authentication. Encryption at rest with integrity verification. Rate limiting on every endpoint. CSRF protection on all forms. Tenant-isolated multi-tenancy with user-level data scoping. Automated threat detection with IP auto-banning. Dedicated background worker architecture. Stripe handles all payments. All connections over HTTPS with HSTS. Continuous static analysis security scanning. Frontend and backend error monitoring with automatic alerting.

Authentication & Access Control

Password security — All passwords are hashed using bcrypt with industry-standard work factors. We never store plaintext passwords.
Account lockout — Accounts are temporarily locked after repeated failed login attempts to prevent brute-force attacks.
Email verification — All accounts require email verification with time-limited tokens.
Two-factor authentication — TOTP-based 2FA with recovery codes. Compatible with any authenticator app (Google Authenticator, Authy, 1Password, etc.).
Multi-provider sign-in — Google, Microsoft, and GitHub OAuth with full state parameter validation to prevent cross-site request forgery during sign-in.
Session security — Sessions are protected with HttpOnly, Secure, and SameSite cookie flags. Session tokens are regenerated on login to prevent session fixation.
Role-based access — Team members are assigned Admin or Member roles with enforced permission boundaries.

Data Isolation

Multi-tenant architecture — Every database query is scoped to the authenticated organisation. Users can never access another organisation’s data.
Team data isolation — All multi-seat plans support configurable isolation modes. In “Separate” mode, team members only see their own contacts, campaigns, calls, and pipeline — with admin oversight via a toggle.
Per-user settings — Email signatures, timezones, contact details, and business context are stored per-user. Team members’ personal settings are never shared or leaked to other members.
Campaign inbox scoping — Campaign email sends are restricted to inboxes owned by the campaign creator. Background workers enforce user-level scoping to prevent cross-user inbox usage.
Background task isolation — All background tasks (email sends, data enrichment, sync) query data by organisation and user ownership. No global state or cross-tenant data access is possible from background workers.

Encryption

Data at rest — All sensitive credentials (OAuth tokens, SMTP passwords, CRM API keys) are encrypted at rest using symmetric encryption with integrity verification.
Key derivation — Encryption keys are derived following NIST recommendations for key stretching.
Data in transit — All connections use HTTPS with HTTP Strict Transport Security (HSTS) enforced.
API tokens — API tokens are cryptographically hashed before storage. The plaintext token is shown once at creation and never stored.

API & Rate Limiting

Distributed rate limiting — Every endpoint is rate-limited with limits shared across all server instances. Stricter limits on authentication, billing, enrichment, and file upload endpoints.
CORS restrictions — API access is restricted to authorised origins only. No wildcard origins are permitted.
CSRF protection — All state-changing requests require CSRF tokens. API endpoints use token-based authentication instead.

Threat Detection

Automated scanner detection — Requests to known vulnerability probe paths (admin panels, config files, CMS endpoints) are detected and tracked per IP address.
IP auto-banning — IPs exhibiting malicious behaviour are automatically banned.
File extension blocking — Requests for known vulnerability file extensions are rejected immediately.

Payment Security

Stripe integration — All payment processing is handled by Stripe. Kolvera never stores credit card numbers or payment details.
Webhook verification — All payment webhook events are verified using cryptographic signatures before processing.
Atomic transactions — Credit deductions are atomic to prevent race conditions or double-spending.

Application Security

XSS prevention — All user-generated content is automatically escaped. HTML email content is sanitised using a strict tag and attribute allowlist.
SQL injection prevention — All database queries use parameterised statements. No raw SQL is used anywhere in the application.
Security headers — Content Security Policy (CSP) with strict source directives, X-Frame-Options (DENY), Strict-Transport-Security (1 year), X-Content-Type-Options, Referrer-Policy, and Permissions-Policy headers on every response. CSP violations reported to error monitoring.
File upload validation — Uploaded files are validated using magic byte inspection (not just file extension), with strict type allowlists and size limits. Upload endpoints are individually rate-limited.
Input validation — Email addresses validated against RFC 5322. Strong password requirements enforced with common password blacklist checking.
SSRF protection — All server-side URL fetching blocks requests to private IP ranges and internal hostnames, preventing server-side request forgery.
Timing-safe comparisons — All token and signature verification uses constant-time comparison to prevent timing side-channel attacks.
Content-type enforcement — Strict content-type allowlists on all upload and API endpoints. Requests with unexpected content types are rejected before processing.

Document Signing Security

Time-limited signing tokens — E-signature links use cryptographic tokens with enforced expiry. Expired tokens cannot be used to access or sign documents.
Signing order enforcement — Multi-party documents enforce sequential signing order. Signers cannot access a document until all prior signers have completed.
Signing rate limits — Dedicated rate limiting on all signing endpoints to prevent abuse of document access links.
PDF validation gate — Only valid PDF documents can be sent for signing. File integrity is verified before any signing workflow begins.

Email Security

Header injection prevention — All email headers are sanitised to prevent injection attacks.
Spam Act compliance — Every outbound email includes a one-click unsubscribe link and business address footer, compliant with the Australian Spam Act 2003.
Cryptographic unsubscribe — Unsubscribe tokens are signed using HMAC-SHA256 to prevent tampering.
DNS health validation — SPF, DKIM, DMARC, and MX records are validated automatically for all connected sending domains. Warnings surface when records are misconfigured.
Bounce protection — Automatic bounce detection with campaign auto-pause when bounce rate exceeds thresholds. Invalid emails are flagged and blocked from future sends to protect sender reputation.
Blacklist monitoring — Sending domains are checked against multiple DNS-based blocklists on a regular schedule. Alerts are raised if a domain appears on any monitored list.
Reply forgery prevention — Inbound reply classification validates message headers and threading to prevent spoofed replies from being injected into campaign conversations.
Dead inbox auto-pause — Mailboxes that become unreachable or fail authentication are automatically paused to prevent delivery failures and protect sender reputation.
Machine open filtering — Automated email opens from security scanners and mail proxies are detected and excluded from campaign analytics to ensure accurate engagement data.

SMS Security

Webhook signature verification — All inbound SMS webhooks are verified using cryptographic signatures. Unsigned or tampered requests are rejected.
Tenant-scoped messaging — SMS conversations are strictly scoped to the originating organisation. Messages are never visible across tenants.

Infrastructure

Cloud hosting — Kolvera is hosted on enterprise-grade cloud infrastructure with automatic deployments from a protected main branch.
Isolated service architecture — The application runs as multiple isolated services. Background tasks run on dedicated processes that are fully isolated from web request handling.
CI/CD pipeline — Every code change passes automated unit, security, and integration tests before deployment. Static analysis security scanning runs on every commit to catch vulnerabilities before they reach production.
Health monitoring — System health is continuously monitored across all services with both backend and frontend error tracking. Client-side exceptions are captured and reported automatically. Issues trigger instant alerts.
Secret management — All API keys, database credentials, and encryption keys are stored as environment variables. No secrets are hardcoded in source code.
Database connection pooling — Connection pooling ensures reliable database access under high concurrency.
Error handling — Application errors are logged internally with full context for debugging. Users never see stack traces, database details, or internal system information.
Container security — Application containers run with minimal privileges and filesystem permissions.
Migration safeguards — Database schema migrations include collision detection to prevent concurrent migrations from conflicting. Migrations are versioned and verified before application.

Third-Party Integrations

Webhook security — All inbound webhooks from third-party providers are verified using provider-specific cryptographic signatures before processing.
OAuth security — All OAuth flows use state parameters with cryptographic nonces to prevent CSRF during authorisation callbacks. State tokens are single-use and time-limited.
Credential storage — Third-party API keys and OAuth tokens are encrypted at rest and never logged.

Kolvera is built and maintained in Australia. We are committed to protecting your data and continuously improving our security posture.

Ready to try it?

50 credits, no card required. See what secure, AU-first recruitment BD looks like.

Start Free Trial

Security at Kolvera