Privacy Policy

• Account data — your email address and a salted, hashed password (scrypt). 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.
• Contact enquiries — if you write to us through the contact form: your name, work email, phone number, 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. As currently implemented that file is not encrypted at rest — anyone with filesystem access to the server has access to it, including the MFA secrets and backup-code hashes. Do not treat this deployment as suitable for highly sensitive data until encryption at rest is added; it 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 and creates no visitor identifier: no cookie, 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 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 indefinitely unless this deployment sets a retention window. When one is configured, a scheduled sweep removes scans older than it — never an asset's most recent completed scan, so history thins rather than disappearing. With no window set, nothing is removed on a timer. 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 deployment, 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.