Security Policy

KillBounce is a focused product that handles a narrow category of customer data (email addresses submitted for verification) and stores it for a short time. We do not operate a dedicated CISO function or a 24x7 SOC; we say that up front because it shapes every security decision on this page.

Our security model is therefore one of data minimisation and defence in depth on the controls that matter. We avoid retaining data we do not need; we use well-established components rather than experimental ones; we encrypt the categories of data a reasonable customer would expect to see encrypted; and the sections below identify the areas where our controls are still maturing.

We also believe that a security page that overclaims is worse than one that underclaims. If you find a discrepancy between this document and what we actually do, we would rather hear about it than have you discover it on your own. See section 10 for how to reach us.

The customer-facing scope of this policy is the production environment of KillBounce, reachable at getkillbounce.com and its subdomains, together with the public API. Development and staging environments are physically separate and do not contain production data.

KillBounce accounts can be created with an email and password, or by signing in with Google or GitHub OAuth. Passwords are hashed using bcrypt with a unique per-user salt and a work factor we tune to remain expensive on current hardware. We never store passwords in cleartext, and we do not log passwords or password reset tokens.

Login endpoints are rate-limited per IP and per account identifier to slow down credential stuffing and brute-force attempts. Reset and verification tokens are single-use, time-bounded, and invalidated as soon as they are consumed.

Session management is based on JSON Web Tokens scoped to the user record. Each user carries a token version counter stored server-side; when a user invokes “sign out everywhere” or changes their password, we increment that counter, which invalidates every JWT previously issued for that account without requiring a database lookup on every request. This gives us global revocation without giving up the performance benefits of stateless tokens.

OAuth sign-ins via Google and GitHub use the providers’ standard OAuth 2.0 flows; we receive only the minimum profile scopes we need (email and a stable user identifier) and we never see or store the customer’s provider credentials.

All public traffic to KillBounce is served over HTTPS. TLS termination happens at our CDN and edge layer (Cloudflare), and connections to our origin from the edge are also encrypted. We require TLS 1.2 or higher; older protocol versions and weak ciphers are disabled.

We send the Strict-Transport-Security header with a long max-age and the preload directive, and our apex domain is on the HSTS preload list. In practice that means modern browsers will refuse to talk to KillBounce over plain HTTP before a single packet is exchanged.

The public API is HTTPS-only. Plain HTTP requests are redirected to HTTPS at the edge and we do not accept API traffic on port 80.

Our primary database is PostgreSQL, self-hosted on our VPS. The underlying filesystem on that VPS is encrypted at rest by the hosting provider, meaning that physical disk theft or recycled-storage attacks would not yield plaintext database contents. Backups follow the same encryption posture (see section 11).

The most sensitive customer data we handle — uploaded email lists and the per-address verification results — is retained for approximately seven days and then purged. Aggregate counters on the user record (e.g. lifetime credits used) survive that purge in non-identifying form. This is described in more detail in our Privacy Policy.

We do not store payment card data. All payment flows are handled by Dodo Payments, our merchant of record. KillBounce never sees the full card PAN, CVV, or expiry; we receive only a transaction reference and the last four digits as a display aid. This keeps cardholder data entirely out of our environment.

Secrets used at runtime (database passwords, API keys to third parties, JWT signing secrets) live in environment files on the VPS, owned by the service user and not readable by other accounts on the host. See section 7.

KillBounce runs on a deliberately small stack. The application backend, PostgreSQL database, Redis instance, and Celery worker all run on a single Webdock VPS in a region we control. The Next.js frontend is deployed on Vercel. Public traffic enters through Cloudflare, which provides our CDN, WAF, DDoS mitigation, and bot protection.

This shape is intentional. A small surface area means fewer places to misconfigure and fewer trust boundaries to reason about. The trade-off is that we do not yet have the regional failover characteristics of a multi-AZ cloud deployment; if our primary VPS is unreachable, the service is unreachable, and we are upfront about that in the trade-off conversation with prospective customers.

The Cloudflare layer applies a managed ruleset that blocks the obvious classes of attack traffic (SQLi probes, well-known scanner signatures, abusive bots) before they touch our origin. Origin access is restricted at the network and application layer to traffic that carries the expected Cloudflare identifying headers.

A complete and current list of subprocessors is maintained on our compliance page and referenced from our DPA.

The KillBounce backend is written in Python (FastAPI) with SQLAlchemy as the data-access layer. All database queries go through SQLAlchemy’s parameterised query interface; we do not concatenate user input into SQL strings. This removes the entire class of first-order SQL injection as a practical concern.

Inbound request bodies are validated by Pydantic schemas before any handler logic runs. Type coercion, range checks, length limits, and shape validation happen at the boundary; handlers receive typed, validated objects rather than raw JSON. Unexpected fields are either rejected or silently dropped depending on the endpoint.

State-changing endpoints called from the browser are protected against cross-site request forgery using a per-session token bound to the authenticated user. API endpoints authenticated with bearer keys do not require CSRF tokens, since the credential is not ambient and cannot be transmitted by a third-party site without the API client’s cooperation.

A Content Security Policy covering scripts, styles, and connect targets is on our short-term roadmap. We mention this here rather than in “what we are not” because the work is in progress; once it ships we will update this page with the specifics.

Production secrets — database credentials, third-party API keys, JWT signing keys, OAuth client secrets — live in environment files on the production VPS. Those files are owned by the service user, have restrictive Unix permissions (readable only by that user), and are excluded from version control and from any build artefacts shipped to the frontend.

Production access is tightly scoped. SSH access to the VPS is restricted to a small set of authorised operators, limited to hardware-backed key pairs with password authentication disabled. There is no “break glass” shared account.

This reflects the company’s current posture. As the operational footprint grows, formal role-based access control, named accounts, and access reviews will be added; we would rather introduce them as real requirements than describe ceremonies we do not yet perform.

The KillBounce public API is authenticated using bearer API keys scoped to a single user account. Keys are generated server-side using a cryptographically secure random source, shown to the user once at creation time, and stored in our database as a hash — we cannot recover the plaintext of a key if it is lost.

Each API key is independently rate-limited using counters held in Redis. Limits are enforced per-key per-window, so a noisy or compromised key cannot starve other keys on the same account. Limits exceeded by a key result in an HTTP 429 response with standard retry headers, not a silent drop.

Customers can rotate API keys from the dashboard at any time: a new key can be issued and the previous key revoked independently, with a configurable overlap window to allow deployments to roll over without a hard cutoff. Suspected compromise of a key should be followed by immediate rotation from the dashboard and a note to security@getkillbounce.com.

Application exceptions and unexpected error states are reported to Sentry, which gives us alerting on new error signatures and a record of regressions. We scrub obvious personal data fields before reporting and we configure Sentry to drop request bodies on endpoints that handle uploaded lists.

Background jobs — bulk verification runs, retention sweeps, scheduled cleanups — are executed by Celery workers with a Celery Beat scheduler. The beat schedule includes the daily purge of expired customer lists, which means retention is enforced by a scheduled job rather than relying on a customer or operator to remember.

We retain structured application logs for approximately ninety days. Logs include request metadata, authentication outcomes, rate-limit decisions, and error stack traces. We deliberately do not log raw email addresses submitted for verification, API key plaintexts, or password material.

We welcome reports from independent researchers. If you believe you have found a security vulnerability in KillBounce, please email security@getkillbounce.com with enough detail to reproduce the issue. PGP is available on request.

We aim to acknowledge reports within five business days and to keep you updated as we triage and remediate. We do not run a paid bug bounty programme today, but we are happy to publicly credit researchers (with their permission) for valid reports.

Safe harbour. If you make a good-faith effort to comply with this policy during your research, we will consider your research to be authorised; we will work with you to understand and resolve the issue; and we will not pursue or support legal action against you. To stay within scope, please: test only against your own accounts; do not access, modify, or exfiltrate data belonging to other customers; avoid actions that would degrade service for other users (no automated scanning that exhausts rate limits, no denial-of-service tests); and give us a reasonable opportunity to remediate before any public disclosure.

Phishing reports, spam reports, missing security headers without a concrete exploitation path, and theoretical issues without practical impact are still appreciated but are unlikely to be treated as severities on their own.

The production PostgreSQL database is snapshotted on a daily schedule. Snapshots are encrypted at rest and retained on a rolling window sufficient to recover from operator error or a corrupting bug. We test restoration from snapshots periodically.

We are upfront that an off-site copy of those backups — i.e. one held in a different physical region, by a different provider — is on our roadmap but is not in place today. A customer whose threat model requires a multi-region durable backup of their verification history should treat the seven-day retention window as the ceiling of what we can guarantee against catastrophic primary loss.

Backups inherit the same retention rules as the live database: when a customer list ages past its seven-day window in production, the next backup taken after the purge will not contain it. We do not maintain perpetual backup archives of customer lists.

To save reviewers’ time: KillBounce does not hold a SOC 2 Type I or Type II report, is not certified to ISO 27001, and is not HIPAA-compliant. We do not have a PCI attestation either, but we also do not handle card data — that is delegated to our merchant of record (see section 4).

We mention this explicitly because it is the question we get most often, and because we would rather lose a deal up front than discover halfway through a procurement review that a customer was relying on a certification we do not have.

If KillBounce’s growth supports the investment, we intend to pursue SOC 2 Type I in 2027, followed by Type II in the following observation window. We will update this page when that work begins, not when we hope to start it. We have no current plans to pursue HIPAA, as the product is not designed for protected health information; customers in healthcare should not upload PHI to KillBounce.

In the meantime, customers who need assurance beyond what is described in this document can request a security questionnaire response or a call with our team via security@getkillbounce.com.

Security reports, questionnaire requests, and vulnerability disclosures: security@getkillbounce.com.

Privacy and data-subject requests: privacy@getkillbounce.com (see Privacy Policy).

Legal notices and contract questions: legal@getkillbounce.com.

General product support: support@getkillbounce.com.