Trust
Security and data handling
An auditing tool that handled data carelessly would be an embarrassing product. Here is exactly what we do.
Scan behaviour
How scans behave
Every scan is a read-only observation of publicly reachable pages. We never attempt authentication bypass, injection, brute force, or any action that modifies target state.
GET requests only - no HEAD, no POST, no form submission, no credentials
robots.txt obeyed, and checked before a URL is fetched rather than after, so a disallowed page is never requested
A declared Crawl-delay is honoured as declared, with no ceiling on it, and while one is in force we drop to a single request in flight - a rate of one request per delay cannot be met by several workers each waiting it out. Ask for a gap so long that a scan could not fetch even its first page within its time budget and we abandon that scan and tell the customer why, rather than crawling you faster than you asked
With no Crawl-delay declared we keep up to 4 requests in flight and at least 250 ms between requests in each of them, so at peak an origin sees at most 16 requests a second from us - not one request every 250 ms. If that is more than you want, Crawl-delay is the lever
Your page budget is enforced before fetching, not after, so a scan never touches more pages than your plan says it will
The user agent is WebAuditOSBot and it links to this page. That link is built from the address the deployment actually answers on, so it never points at a domain we have not switched on yet - and where a deployment has no public address, we send the name with no link rather than a dead one
An unreadable robots.txt is not permission. If yours answers 401, 403, 429 or a 5xx we treat the whole site as disallowed, crawl nothing and tell the customer why - 404 and 410 mean no robots.txt exists, which is the one answer we read as 'no restrictions', because that is what it means. The exception is a connection that fails outright: we cannot tell that apart from a site that is down, so the crawl goes ahead with no robots data and a site we cannot reach is reported as unreachable rather than as having blocked us
Opting out
How to stop us crawling your site
Two ways, and the first needs nothing from us. If you run the site, robots.txt is the fastest and it takes effect on our very next request.
- Add this to your robots.txt: User-agent: WebAuditOSBot then Disallow: / - we read the product token WebAuditOSBot, not the full user-agent string, and a rule naming us beats a permissive wildcard group
- Prefer a slower crawl to none? Crawl-delay in the same group is honoured exactly as you write it, with no upper limit, and we drop to one request in flight while it applies - and if the gap you ask for is longer than a scan's time budget can cover, that scan is abandoned rather than sped up
- The other way is our do-not-scan list: verify control of your domain at /opt-out by publishing one DNS TXT record, and choose to block future scans, erase the scans we already stored, or both. The block covers subdomains and applies to every plan and to the public scanner - a paying customer naming your domain is refused too
- The form insists on DNS verification because an unverified request could block a competitor, or a domain somebody else legitimately owns and is entitled to audit. Rather write? [email protected] still works - and coming OFF the list goes through that address too, so a block cannot be lifted by whoever finds a form
Storage
What we store
We store the analysis, not the internet. Findings, headers, metadata, scores and screenshots are retained; full page bodies are discarded after processing.
Retained: URLs, status codes, response headers, metadata, computed findings, scores, screenshots
Discarded after analysis: full HTML bodies, third-party asset payloads
Never collected: end-user personal data from your visitors
Access control
Workspace controls
Five roles - owner, admin, agency, member and read-only client viewer - registered in the auth layer, not just in the UI. Roles limit what someone can change: a client viewer still reads every project, so a client who should see one site gets a share link
Row-level isolation between workspaces
Append-only audit log of sign-ins, scans started from the app or the API, batch scan runs, report generation, share link creation and revocation, invitations, membership and role changes
Scoped API keys, stored only as a hash, with per-key revocation
No SSO or two-factor yet - sign-in is e-mail and password. Both are on the roadmap and neither is available on any plan today
Retention
Residency and retention
Retention follows your plan - 30 days on Free, 90 days on Starter, 12 months on Pro, 24 months on Super, 24 months on Agency, Custom on Enterprise - and a pruner enforces it rather than the number being an intention, save that the newest scan of each of your own projects is kept beyond the window until you delete the project or the workspace, so a dashboard does not go blank; competitors you benchmark against get no such exception. Deleting a project or a workspace deletes its scans, findings, screenshots and reports at once, in the same request.
The application, the scan workers and the database run in the EU - Amsterdam and Frankfurt - and screenshots, report PDFs and encrypted backups are held in buckets under Cloudflare's EU jurisdiction. None of this is a per-workspace setting: there is no region selector, and a workspace cannot be pinned to a region of its choosing.
Disclosure
Reporting a vulnerability
Send disclosures to [email protected] with "security" in the subject. Be aware of what this is and is not: one mailbox read by one person, with no bug-bounty programme, no published triage times, no safe-harbour statement and no CVE coordination. We will read it and reply; we are not promising anything beyond that yet.
Safe harbour
The safe harbour applies from now, channel or not: we do not pursue legal action against good-faith research that respects user privacy and avoids degrading the service. When the channel opens, a useful report carries reproduction steps, plus the target URL and roughly when it happened if it involves our scanner: each scan records its target and its start and finish times, so those two are enough to identify the run. We do not keep a per-request log, so an exact request cannot be looked up - the window can.
Related guide
Security headers: what each one does, and what it breaks
What HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy and Permissions-Policy actually do, the order to add them in, and what each one breaks on the way.
Read the guide →