Security

No certifications to show you, so here is the thing underneath them: what Simplytics actually does, what it deliberately never holds, and what is still wrong with it.

The part that matters most: what is not here

Most analytics breaches are bad because of what the tool was keeping. Simplytics keeps almost none of it, which is a design decision rather than a security control — but it is the one that limits the damage of everything else.

• No passwords. There is nothing to hash, leak, reuse or crack. You sign in with Google, with GitHub, or with a link emailed to you.
• No cookies on your visitors, and no visitor identifier that survives the day. The daily hash is HMAC-SHA256 over a truncated IP, the user-agent and the domain, keyed with a secret and re-salted at each site's local midnight. Without the key the space is not enumerable; with the day gone the hash is not linkable to tomorrow's.
• No raw visit records after the night. Individual rows exist only to count a unique visitor within one day, and the nightly job deletes every completed day. Funnel journeys lose their visitor identifier at the end of the day and the rows themselves are deleted after 90 days.
• No card numbers. Dodo Payments is the merchant of record and we never see them.
• No names, pictures or profiles. Google is asked for openid email and GitHub for user:email — the address and nothing else.

How the account itself is protected

• Sessions are opaque 256-bit ids stored server-side, in an HttpOnly, Secure, SameSite=Lax cookie. Signing out deletes the row, not just the cookie.
• Emailed sign-in links live 15 minutes, work once, and are stored only as a SHA-256 hash — a copy of the database is not a set of working keys. Opening one shows you which address you are about to sign in as before anything happens, which is what stops someone mailing you their link.
• Cross-site request forgery has two layers: SameSite=Lax on the session cookie, and an Origin/Sec-Fetch-Site check on every mutating request. The beacons are excluded because they are cross-origin by design, and the webhooks because an HMAC signature proves more than either header could.
• Webhooks from the payment provider are verified against an HMAC signature and de-duplicated by event id before anything is granted or revoked.
• Rate limits sit in front of sign-in, the beacons, the dashboard and the webhooks, keyed per IP — and the beacons additionally per site key, so one site cannot spend the whole account's budget from many addresses.

Transport and headers

• HTTPS is forced at the edge, minimum TLS 1.2, with HSTS for a year including subdomains.
• X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that turns off camera, microphone and geolocation.
• The two third-party scripts the dashboard loads are pinned to exact versions and checked against Subresource Integrity hashes, so a compromised CDN cannot change them.

Where the data is, and what happens if it is lost

• Analytics live in a Cloudflare D1 database whose primary storage is in the European Union (Warsaw).
• A full database export is written weekly to a private, EU-jurisdiction object store. The restore path has been exercised end to end — a dump loaded into a scratch database and its tables counted — rather than assumed from the fact that a file exists.
• You can export everything as CSV yourself at any time, subscribed or not, and delete your account and every byte of its data from the Account page.

What is still wrong

A security page that lists only good news is an advertisement. These are the open items, in the order we would fix them:

• The Content-Security-Policy still allows 'unsafe-inline' for scripts. That means the header is an inventory of where code may come from, not a defence against injected script. Fixing it means moving the inline handlers out and adding nonces, and until that lands the header should not be read as protection.
• One person builds and runs this. There is no second pair of eyes on a deploy, no on-call rotation, and no separation of duties. The mitigations are that the blast radius is small by design and that everything ships through automated tests and a smoke check, but neither is the same thing.
• No SOC 2, no ISO 27001, no third-party penetration test. Each costs more than this product earns. If you need one of them to buy, Simplytics is honestly not the right tool for you yet.

Reporting something

Email nikhil@simplytics.dev. There is no bug bounty and no payout — saying so plainly is fairer than letting you spend a weekend assuming otherwise. Reports are read and answered, and /.well-known/security.txt lists what is already known and therefore not worth your time.

Please do not test against other people's accounts or send traffic that would distort a customer's numbers. A free trial takes no card and gives you a real account of your own to test against.