Privacy Policy
Last updated
This service runs as a single deployment operated by Webcuris: the data it collects stays in that deployment's database. Your scan results are not shared with or sold to anyone, and there is no third-party analytics or advertising tracker anywhere in the product. Page views are counted by this application itself, in a way that creates no visitor identifier — described in full below.
On this page
What is stored
- 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.
Where it lives
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.
Third parties
A scan is not a purely local operation — it reaches out to public vulnerability and certificate databases. Every outbound destination is listed here.
| Service | When | What is sent |
|---|---|---|
| OSV.devGoogle / OpenSSF | Repository scan | Package names and versions only. No source code or file contents are sent. |
| Cloudflare DNS-over-HTTPSCloudflare | Website scan | The hostname of the scanned site, to check for a DNSSEC signal. |
| crt.shSectigo | Website scan | The domain being scanned, queried against public Certificate Transparency logs to discover subdomains. |
| FIRST.org EPSSFIRST | Dependency findings | CVE identifiers already present in a finding, to retrieve public exploit-prediction scores. |
| GitHubGitHub / Microsoft | GitHub repository scan | The repository and branch you asked to scan, cloned over HTTPS. No credentials are sent — only private repositories are supported using a read-only credential you supply. |
| The target you scanYou or the site's owner | Every scan | Standard HTTP/TLS/DNS requests, since scanning a target requires connecting to it. |
| Your alert destinationYou choose | Monitoring alerts only | Scan summaries — asset URL, score, and new or regressed finding titles and severities — to a webhook URL, Slack, PagerDuty, Datadog, or Splunk endpoint you configure. |
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.
Contact and grievances
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.
This deployment has not published a contact yet
Whoever operates this instance is required to publish a data-protection contact point. It is not configured here: GRIEVANCE_OFFICER_NAME, GRIEVANCE_OFFICER_EMAIL are unset. Until that is done, direct any request to the operator through whatever channel you reached them by.
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.
Retention and deletion
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.