veriastra_
Legal

Security

Last updated August 19, 2026

This page describes what we actually do, and says plainly what we do not have yet. A security page full of badges we have not earned would be the first thing worth distrusting about us.

Architecture

Veriastra runs on a dedicated server under its own operating-system account, isolated from any other application on the machine, with its own process supervisor and least-privilege file permissions. Traffic reaches it only through a reverse proxy; the application itself is not exposed to the public network directly.

Browser isolation

HTML responses carry a Content-Security-Policy with a fresh nonce on every request. Inline script we did not stamp with that nonce cannot run. Same-origin scripts are allowed so Cloudflare's email-address decoder — which we do not emit — can still run; without it, addresses on the page stay obfuscated. We still allow inline style attributes because React writes them; that is weaker than the script policy and we do not pretend otherwise. The only third-party origins the policy names are the ones the browser actually calls: api.ipify.org (the "use my IP" control on free tools) and Paddle (overlay checkout when that provider is selected). Polar and Stripe checkout are top-level redirects, so they do not need a slot.

Encryption in transit

All public traffic is HTTPS. HTTP is redirected, the minimum TLS version is 1.2, and the connection between our edge and the origin uses a dedicated certificate rather than an unauthenticated tunnel. We use Cloudflare for DNS, TLS termination, and CDN.

API keys & authentication

API keys are stored hashed with SHA-256 and never in plaintext: a leaked database row does not yield a usable key. Keys can be revoked from the dashboard and take effect immediately. Account sign-in uses Better Auth with Google OAuth, so we never store a password. Sessions have a bounded lifetime and requests are checked against trusted origins.

Abuse & request safety

Free-tier requests are rate-limited per client with both per-minute and daily ceilings. Those counters live in the same store as the rest of the operational data, so a process restart does not hand every visitor a fresh allowance. Outbound requests made on your behalf, such as domain and website checks, pass through an SSRF guard that blocks private ranges, loopback addresses, cloud metadata endpoints, and encoded equivalents, so the Service cannot be used to reach internal systems.

Data handling & retention

We keep the minimum needed to answer requests and prevent abuse. Result caches are short-lived per data type, bulk job inputs and results are purged after about 30 days, and IP reputation records after about 180 days. Purges run automatically on a daily schedule, not on request. Full detail is in the Privacy Policy.

Backups & recovery

The account and credit database is snapshotted daily using a consistent copy, with a short rotation kept on disk. The restore procedure has been executed and verified, not just written down. Reference datasets are not backed up by design: they are rebuilt from their sources by the daily collectors, which is faster and cheaper than restoring them.

Monitoring

A daily health check covers process liveness, disk headroom, and recent error volume, and alerts us when a threshold is crossed. We also monitor our outbound mail-probe address against public blocklists so a reputation problem surfaces before it affects results.

What we do not claim

We are a small team and we would rather you know the limits than discover them:

  • No SOC 2, ISO 27001, HIPAA, or PCI certification. We do not store card data: payments are handled by our payment provider and card details never touch our servers.
  • No third-party penetration test has been published. Our hardening comes from internal review, and the findings were fixed and verified in production.
  • No multi-factor authentication of our own. Sign-in is delegated to Google, so your Google account's MFA protects it.
  • No contractual uptime guarantee unless we sign a separate SLA with you.

Reporting a vulnerability

Email [email protected] with enough detail to reproduce the issue. We will acknowledge within a few business days and keep you updated until it is resolved. Please give us reasonable time to fix an issue before disclosing it publicly, and do not access, modify, or exfiltrate data belonging to anyone else while testing. We will not pursue legal action against researchers who follow this in good faith. We do not currently run a paid bounty program.