Privacy Policy

• Account data — your email address and a salted, hashed password (scrypt). Optionally a first name, last name and company name, if you choose to add them on your profile; they are used to address you in email and nowhere else, and clearing a field removes it. Plaintext passwords are never stored. If you enable two-factor authentication, a TOTP secret and hashed backup codes are stored alongside it.
• Session data — a random session token is stored client-side as an httpOnly cookie; only its SHA-256 hash and expiry are stored server-side.
• Scan data — submitted URLs or filesystem paths, and the full results of each scan: HTTP headers, TLS certificate details, DNS records, page HTML sampled for mixed-content detection, dependency names and versions, and secret-scan matches with the matched value partially masked before it is written.
• Audit entries — actor, action, target, and originating IP address for security-relevant events such as logins, scans, and settings changes.
• Billing data — held by Polar, our merchant of record, not by us. They are the seller on your transaction, so your name, billing address, country and payment details are given to them and we never see a card number. What this application stores is the plan you are on, how it is billed, when the period ends, and Polar’s identifier for the subscription — enough to know what you are entitled to, and nothing that could be used to charge you.
• Bot-check signals — sign-up, sign-in, password reset, two-factor verification and the contact form are protected by Cloudflare Turnstile, which receives your IP address and browser signals in order to decide whether you are a person. It is a check, not a login: we receive only pass or fail, and nothing about you is stored here as a result of it.
• Contact enquiries — if you write to us through the contact form: your name, email address, phone number if you give one, and message, plus a network prefix (never your full address) and whether you ticked the optional marketing box. Marketing consent is recorded only when you tick it; your message is answered either way, and you can withdraw at any time by replying.

All of the above is stored in a local SQLite database file on the server running the application. The file itself is not encrypted at rest, so anyone with filesystem access to the server can read the rows. What they cannot read is the contents of the fields that matter most: TOTP secrets, repository access tokens and scan evidence are sealed individually with AES-256-GCM under a key held outside the database, so a copy of the file yields ciphertext for those columns rather than values. Whether that sealing is switched on is a setting of the service and is reported on the enterprise page, which reads the key ring rather than asserting an answer. Full-file encryption is still not in place and is tracked as a known limitation in the Security Policy.

A scan is not a purely local operation — it reaches out to public vulnerability and certificate databases. Every outbound destination is listed here.

No data is sold, and no third-party analytics or advertising service receives anything about your visit. You control the alert destination and are responsible for where it points.

One strictly-necessary cookie (session) keeps you signed in. It is httpOnly and not readable by JavaScript. The product additionally remembers a light/dark theme choice in localStorage, which never leaves your browser. No analytics or marketing cookies are set.

We do count page views, using measurement built into this application rather than a third-party analytics service. It stores nothing in your browser — no cookie, no localStorage, no sessionStorage — and creates no visitor identifier: no fingerprint, no hash of your address and browser. Pages are recorded as route patterns rather than URLs, referrers as a bare hostname, your address is used to rate-limit the endpoint and to derive a country code and city name (“Mumbai, IN” — matched against tables held locally by Webcuris, never sent to any geolocation service, no coordinates kept) and then discarded, and your user agent is never read. The consequence, stated plainly, is that we can count page views and cannot count unique people — the full detail is on the Cookie Policy.

If you have a question about how your data is handled, want a copy of it, want it corrected or erased, or want to complain about any of it, this is where to write. You do not need a reason, a form, or a lawyer.

We aim to acknowledge within a few working days. Account holders can also export their data and delete their account themselves, without asking anyone, from the account page — the fastest route for both requests is the one that does not involve us.

If you are unhappy with the response, you can escalate. Under India’s Digital Personal Data Protection Act 2023 you may complain to the Data Protection Board of India. If you are in the UK or European Economic Area, you may complain to your local supervisory authority. Neither route requires our permission or our involvement.

Scan history, findings, and account data are retained until you delete them, unless a retention window is in force. The Data Retention page states the period in force, and with one set a scheduled sweep removes scans older than it — never an asset's most recent completed scan, so history thins rather than disappearing. Deletion and export are yours to run either way, without asking anyone.

• Export. /account → “Download export” returns everything held about you as JSON: assets, scans, findings, triage decisions, API key metadata, agent sessions, organisation memberships, and your audit-log entries. Raw scan evidence is excluded because it describes third-party systems rather than you; it is downloadable per scan.
• Deleting an asset removes it and every scan, finding and track belonging to it, for all users who have scanned it. It requires typing the hostname back, and cannot be undone.
• Erasing your account removes your account and everything attributable to you. It requires your password even though you are already signed in.

Two things about erasure are worth stating plainly, because they are deliberate choices rather than oversights. An asset that a colleague has also scanned is kept but anonymised — your identity is stripped from it — because deleting the shared record would destroy their history to satisfy your request. And audit-log entries are kept with your email redacted rather than deleted: the log is hash-chained, it is the record of security-relevant actions for everyone on the service, and removing rows would break that chain. Erasure of the personal data in it is achieved by redaction instead.

Erasure is refused, with the reason given, if you are the only owner account or if you own an organisation that still has other members — in both cases proceeding would damage someone else.