Skip to content
SitesProof
Scan a page

Menu

Security

Version 1.1 · Last updated 2 October 2026

SitesProof is built and run by one person. We don't have a security team or a SOC 2 report, so this page explains plainly what we do to protect your data, and what we don't do.

Contents

  1. Where your data lives
  2. Encryption
  3. Access
  4. How we build and run the product
  5. Backups and deletion
  6. Product-specific measures
  7. What we don't have (yet)
  8. Reporting a vulnerability

1. Where your data lives

The application and database run on servers rented from Hetzner in Germany (EU), in ISO 27001-certified data centres. Cloudflare sits in front of the site for DNS, TLS and protection against attacks. Other services that receive data are listed on the Subprocessors page.

2. Encryption

  • All traffic uses HTTPS (TLS 1.2 or newer), with HSTS.
  • Disks and database backups are encrypted.
  • API keys, access tokens and other credentials for systems you connect are encrypted again inside the database (libsodium sealed boxes) with a key that is stored separately from the database. They are decrypted only in memory when a job needs them, never shown back in full, and never written to logs.

3. Access

  • Only the founder can access production systems, using SSH keys and two-factor authentication on every admin account (hosting, DNS, source code, email, payments).
  • Automated deployments use a separate key with limited rights.
  • We look at your data only when needed to support you, fix a problem you reported, or investigate abuse or a security issue.
  • Sign-in uses email and password or Google. Passwords are stored only as salted, slow hashes (never in plain text), and we never see them.

4. How we build and run the product

  • Every database query is scoped to your organisation, and automated tests check that one customer can't see another's data.
  • Dependencies are kept up to date and scanned for known vulnerabilities.
  • Staging and production are separate; staging never contains production personal data.
  • Errors and logs are kept on our own server for 30 days, and we scrub personal data (request bodies, tokens) from error reports.
  • Uptime is monitored every minute and alerts go to the founder.
  • We follow a written incident procedure. If a breach affects your personal data, we will notify you within 48 hours of becoming aware of it (see the DPA).

5. Backups and deletion

  • The database is backed up nightly and backups are kept for 60 days. We test restores regularly.
  • When you delete data or close your account, it is deleted from the live system within 30 days and from backups as they expire.

6. Product-specific measures

Two things in SitesProof need measures the list above doesn't cover: a crawler that visits other people's websites, and a URL box on a public page that anyone can point anywhere.

  • The public scanner's outbound requests are guarded. Every request it makes goes through one fetch path that refuses loopback, private, link-local and other non-public address ranges — including when a hostname resolves to one. The resolved address is pinned for the request and re-checked on each redirect, redirects and response size are capped, every request has a timeout, and schemes other than http and https are refused. A request we cannot verify as safe is refused rather than attempted.
  • The scanner fails closed. It is protected by a captcha, and if the captcha cannot be verified the scan is refused. The same address can be scanned once an hour.
  • The crawler is polite and identifiable. It reads robots.txt before anything else and obeys the rules for its own user agent; a robots.txt it cannot read is treated as "do not crawl". Requests identify themselves as SitesProofBot with a link, so a site owner can recognise and rate-limit us.
  • Crawl artifacts hold hashes, not content. Cookie values and page bodies are never stored (see the Privacy Policy, section 4). Artifacts are kept in private storage, with no public access, for no longer than 90 days, and removing a site removes its artifacts.
  • A shareable report link is twelve random characters — about sixty bits — because the link is the only thing protecting that page. Those pages are excluded from search engines and carry no page bodies and no element selectors.
  • One account cannot see another's portfolio. Every dashboard query is scoped to your own organisation through the client that owns the site, never to an identifier taken from the page, and tests check it.

Nothing in SitesProof ever modifies a site it looks at. There is no overlay, no injected script and no automatic fix — by design, not by omission.

7. What we don't have (yet)

  • No SOC 2 or ISO 27001 certification of our own (our hosting provider is certified).
  • No 24/7 on-call team: alerts reach one person, so outside business hours in Central/Eastern Europe responses can be slower.
  • No bug bounty with payouts, but we are grateful for reports (see below) and will credit you if you like.

If your organisation needs a security questionnaire answered, email support@sitesproof.com.

8. Reporting a vulnerability

Email security@sitesproof.com with details and steps to reproduce. Please give us reasonable time to fix the issue before disclosing it, don't access or change other people's data, and don't run tests that degrade the service (no load or denial-of-service testing). We won't take legal action against good-faith research that follows these rules. We aim to acknowledge reports within 3 business days. A machine-readable contact is at /.well-known/security.txt.