Security at Scan.now

We grade other sites on security, so we expect to be held to the same standard. This page is the human version of our security.txt.

Illustration of a security.txt file and a responsible disclosure report

Reporting a vulnerability

Email [email protected] or use the contact form with the topic “Security report”. Include the URL, the steps to reproduce and the impact you believe it has. We acknowledge reports within three working days and aim to fix confirmed issues within thirty. Our machine-readable policy is at /.well-known/security.txt (RFC 9116).

What we ask

  • Do not access, modify or delete data that is not yours. If you reach other people's data by accident, stop and tell us.
  • Do not run denial-of-service tests or automated scanners at high rates against the scanning endpoints.
  • Give us reasonable time to fix an issue before publishing it.

What we promise

  • We will not take legal action against good-faith research that follows the points above.
  • We will keep you informed and credit you here if you wish.
  • We will not ask you to sign anything to receive a fix.

How the service itself is protected

  • Every outbound request made by a scanner is checked against private, loopback, link-local and metadata address ranges, before and after each redirect.
  • Uploaded files are held in memory only, never written to disk and never executed.
  • Responses carry a nonce-based Content-Security-Policy, HSTS with preload, frame-ancestors 'none', nosniff, a strict Referrer-Policy and a Permissions-Policy. No third-party fonts are loaded. The one script from another origin is our own self-hosted Matomo, which sets no cookies; the policy names that single origin and nothing else.
  • Scan endpoints are rate-limited per address and protected against cross-site requests with tokens that expire.
  • Sign-in is optional and delegated to Google. We never see, receive or store a password, and there is nothing on this site to brute-force.
  • Scans work fully without signing in, so an account is never a condition of using the service.

What is in scope

  • This website and its scan endpoints.
  • The browser extension.
  • Anything that lets one visitor reach another visitor’s report, or reach a host our scanners should refuse.

What is out of scope

  • Findings about sites we scanned. Those belong to their operators; report them there.
  • Missing headers on our own marketing pages that carry no user data and no state.
  • Automated scanner output with no demonstrated impact. We run the same kinds of tools; send us the consequence, not the row.
  • Denial of service and volumetric testing. Please do not, on a service anyone can use for free.

Where to look first

If you want the fastest route to something real: The scanners fetch URLs you control, which makes server-side request forgery the most interesting class here, and the reason every outbound request is checked against private address ranges before and after each redirect. The second is report tokens. Both are described in how we scan, and we would rather tell you where the interesting parts are than have you spend a weekend on the marketing pages.