Security
How we protect your data
Concrete technical controls, not generic bullet points. Everything below describes what the product actually does. If a claim looks unverifiable, ask us about it on a security review call.
Last updated: May 2026
Account security
How we protect your Predax account itself.
- Password storage
- Passwords are hashed with bcrypt (12 rounds) before being stored. Plaintext passwords never touch disk and are never logged. The 12-character minimum length plus a server-side check against a list of common passwords closes the most-abused attack surfaces at signup.
- Two-factor authentication
- TOTP-based 2FA per RFC 6238 — works with Google Authenticator, Authy, 1Password, and any standard authenticator app. Single-use backup codes are generated once at setup and stored bcrypt-hashed. Disabling 2FA requires re-entering your password to prevent session-hijack-based downgrade.
- Magic-link sign-in
- Passwordless sign-in option. Magic links are single-use, expire in 15 minutes, and bind to the requesting IP and user-agent for replay detection. Successfully clicking a link also marks the email as verified.
- Session invalidation
- Every account has a session_version counter. Changing your password or resetting it via email increments the version and invalidates every active session immediately — including any token an attacker might have stolen.
- Cookie hardening
- Session cookies are HttpOnly, Secure (in production), SameSite=Lax, and scoped to the Predax domain. JavaScript on your dashboard cannot read the access token. Mutating endpoints additionally require an X-CSRF-Token header that the server cross-checks against a separate, JS-readable cookie.
- Brute-force protection
- Login attempts are rate-limited per IP (20 / minute) and per email (sliding window with exponential backoff). Failed attempts trigger a temporary lockout. Constant-time bcrypt comparison runs even for unknown emails to prevent timing-oracle account enumeration.
- Active session management
- See every active session for your account on Dashboard → Security, with device, IP, location, and last-seen timestamp. Revoke individual sessions or every session except the current one with a single click.
API security
How we protect your API keys and the data flowing through them.
- Hashed key storage
- API keys are SHA-256 hashed before being stored. The plaintext value is shown to you exactly once at creation time and never again — neither Predax staff nor a database breach can recover it. If a key is lost, you generate a new one and revoke the old.
- Key rotation with overlap
- Rotate any key from Dashboard → API Keys. The new key activates immediately and the old key remains usable for 24 hours, giving you a clean swap window without downtime in your application.
- Per-key IP allowlists
- Restrict each API key to specific source IPs or CIDR ranges. Useful for production keys that should only ever be called from your servers — a leaked key from a different IP gets rejected before any business logic runs.
- Rate limiting
- Per-second sliding-window limiting backed by Redis. Plan-based per-day quotas (1,000 / 2,000 / 5,000 / 17,000 depending on tier) and per-month limits. Quota notifications fire at 80%, 90%, and 100% so you have time to react before throttling kicks in.
- TLS 1.3 in transit
- All traffic to api endpoints is HTTPS-only with TLS 1.3 preferred. HTTP requests are 301-redirected. HSTS is enforced with a 6-month max-age. Caddy handles certificate issuance and rotation automatically via Let's Encrypt.
- Auth scheme diversity
- Two distinct authentication paths — X-API-Key header for integrations and httpOnly JWT cookies for the dashboard. CSRF protection is enforced on cookie-based requests; API-key requests are stateless and CSRF-exempt.
Data protection
How we store, retain, and dispose of customer data.
- Encryption at rest
- PostgreSQL data files reside on AES-256 encrypted volumes. Backups are also encrypted at rest. Redis runs in-memory only with no on-disk persistence of customer-identifying data.
- Daily backups
- Database backups run daily at 01:00 UTC via Celery Beat, retained for the rolling backup window. Restoration is rehearsed end-to-end as part of incident-response readiness.
- Request log retention
- API request logs are retained for 90 days, then automatically deleted by a daily retention cleanup task. Logs include endpoint, status code, latency, and timestamp — never request bodies, response bodies, or your end-users' personal data.
- Audit log retention
- Security-relevant events (logins, key rotations, password changes, 2FA enable/disable, admin actions) are written to the audit log with IP and user-agent context, available to you in real time at Dashboard → Audit Log. Audit log entries are retained for the lifetime of the account.
- No third-party tracking on lookups
- IP intelligence requests are not shared with ad networks, marketing pixels, or any third party. The lookup data flows from your application to our API and back — that's it.
Privacy and compliance
Legal and regulatory positioning.
- GDPR / UK GDPR
- Predax is operated from the United Kingdom. All processing of personal data is governed by UK GDPR. Our Privacy Policy describes the lawful bases (legitimate interest for IP processing in security context, contract for billing, consent for marketing). End-users whose IPs you check have the same data subject rights as your direct customers.
- Data Processing Agreement
- A DPA is available for download from /dpa. Signed copy on request — contact [email protected]. Sub-processors (currently Hostinger UK Limited for hosting, Stripe for billing, SendGrid for transactional email, OpenAI for the support assistant) are listed in the DPA with the type of data processed by each.
- Email consent (PECR / GDPR Article 6)
- Marketing and weekly-report emails are governed by per-category preferences (Dashboard → Email Preferences). RFC 8058 List-Unsubscribe headers are included so Gmail and Apple Mail one-click unsubscribe works as expected. Transactional mail (verification, password reset, billing receipts) is contractual and always sent.
- Data residency
- All production data is stored in the United Kingdom. No cross-border transfer takes place for the hosting leg. Stripe and SendGrid are US-based sub-processors covered by IDTAs (UK's SCC equivalent) for the necessary transfers.
- Data export and deletion
- Account deletion is available on request via [email protected] and processed within 30 days, including erasure from backups within the next backup-rotation window. Data export (your audit log, request logs, and account data) on request — same channel.
Audit and monitoring
How we detect and respond to anomalies.
- Structured logging
- All application logs are structured JSON with request IDs, user IDs (where applicable), and event categories. This makes correlation, alerting, and incident-response forensics tractable rather than grep-driven.
- Real-time anomaly alerts
- Notable events (new account registration, suspected brute-force, password reset requests, admin actions) trigger real-time Discord alerts to the security channel. Operators see anomalies in seconds, not on the next log review.
- Health monitoring
- /health and /health/details endpoints are polled continuously by a Celery-based monitoring task. Database pool, Redis connectivity, feed freshness, and SSL certificate expiry are all checked. Sustained failure routes to on-call.
- User-accessible audit log
- Every customer can see their own audit log (Dashboard → Audit Log) with action type, IP, user agent, and timestamp. No need to email support to find out who did what — the data is yours.
Infrastructure
What we run on.
- Hosting
- Production runs on Hostinger UK Limited infrastructure in the United Kingdom. The DPA and Privacy Policy list Hostinger as our sole hosting sub-processor. Network ingress passes through Caddy as a reverse proxy with automatic TLS.
- Stack
- PostgreSQL 15 (primary store), Redis 7 (cache + rate-limiting backend), Celery (background tasks + scheduled jobs), FastAPI (Python 3.11 application server), Next.js 16 (frontend). All services run in Docker containers on a single multi-tenant VPS.
- Configuration management
- Secrets live in environment variables, not source code. Production .env is restricted to the operator account. No secrets are ever committed to source control. Plaintext API keys are never logged, even at debug level.
- Patch cadence
- Operating-system security updates applied weekly (or immediately for high-severity CVEs). Application dependencies tracked via requirements.txt and package.json with regular review. Container base images rebuilt on every deploy, picking up upstream security patches.
Vulnerability disclosure
If you find a bug, here's how to tell us.
- Reporting channel
- Email [email protected] with a description of the issue, reproduction steps, and your contact details. PGP key available on request. We aim to acknowledge within 24 hours and provide an initial assessment within 72 hours.
- Safe harbour
- Good-faith security research is welcomed. We will not pursue legal action against researchers who report vulnerabilities responsibly, give us reasonable time to fix before disclosure, and do not exploit findings beyond what is needed for proof-of-concept (no data exfiltration, no DoS, no targeting of customer accounts).
- Out of scope
- Volumetric DDoS, social engineering of staff, physical security of our hosting provider, third-party services we depend on (report those upstream), and findings that require pre-existing administrative access. We cannot pay bug bounties at this time.
What we don't claim
We'd rather flag the gaps explicitly than pretend they don't exist.
- No SOC 2 attestation
- We do not currently hold a SOC 2 Type 1 or Type 2 attestation. Pursuing an audit makes sense once customer demand justifies the cost (typically when serving regulated enterprise buyers). For now: the controls described above are real and verifiable in the product itself.
- No ISO 27001 certification
- Same answer — not certified. The information security practices on this page describe what we actually do, not what an auditor has signed off on. Happy to walk through specifics on a security review call.
- No published penetration test
- We have not commissioned an external pentest. As the customer base grows we will. In the meantime, the published vulnerability disclosure process (above) is open to you.
- Single-tenant database, multi-tenant application
- All customer data lives in one PostgreSQL database, separated by user_id at the row level (with foreign-key cascade and ORM-enforced filtering). No customer-isolated database instances. This is the standard SaaS model — flagged here so you can make an informed call.
Security questions?
Email [email protected] for vulnerability reports or contact us for security review or DPA requests.