Your code never leaves your machine

Scan data stays on your machine

Everything below is stored in a local SQLite database on your device. None of it reaches a SiteCMD server or any third party unless you connect that site, which is the next section.

• Your source code, file paths, and file contents
• Page HTML, response bodies, and screenshots
• Scan results, scores, and issue history, unless you connect the site
• Project names, URLs, and configuration, unless you connect the site
• Core Web Vitals measurements and accessibility results, which stay in the local scan record
• Cookies, storage, or cache shared with your browser or carried over between scans
• Any new window, any download, or any top-level navigation to an internal address
• Any query to a SiteCMD-controlled or hardcoded third-party DNS service
• Scan results, page content, or anything beyond the domain name being looked up

Scanning a site does mean talking to it. These requests go from your machine to the site being scanned and to your own resolver, never to us, and nothing they return is relayed anywhere.

• The scanned page itself, loaded in a hidden private webview to measure Core Web Vitals and, when accessibility analysis is on, run axe-core. The subresources that page then requests - images, scripts, stylesheets, fonts, fetch calls - are fetched by the platform's browser engine, to the hosts the page names, exactly as they would be if you opened it yourself. SiteCMD neither chooses those requests nor can intercept them, and scheduled scans run this layer too
• The scanned site's domain name, as standard DNS queries (SPF/DMARC/DKIM/MX/DNSKEY/CAA, plus a CNAME and address lookup for the www subdomain to catch dangling aliases) to the machine's own configured DNS resolver - the same resolver every other app on the machine uses

The far side of that conversation is documented too. What the scanner requests lists every kind of request a scanned site receives, the identity SiteCMD sends, and how to block it.

Connecting a site, and what that changes

A connected site is the one feature that sends findings to a SiteCMD server. It is off until you connect one, there is no background sync, and an installation that never connects never contacts that host at all.

What travels is a finding's identity, not its evidence: the check, its severity, the route on your site it fired on, and for a code finding a keyed hash of where it fired, computed under a key that stays on your device. Your source, your file paths, and your line numbers have no field to travel in. The row in the table below is the whole list, and the app shows you the same payload before it sends one.

Connecting a site also changes who does the scanning. A connected site can be scanned from SiteCMD's own infrastructure, on a schedule and with the app closed, and those requests leave our network rather than yours. The hosted transport explicitly reaches one service host, marked "SiteCMD's service" in the table below: Cloudflare's public DNS-over-HTTPS resolver, which it asks for address records before every transport or intercepted browser fetch. A full scan also renders the page in Cloudflare Browser Run, so the page's own scripts and markup can request public HTTPS subresources from hosts the page names. The Worker fetches each bounded response through public egress and fulfills it into Chromium. That dynamic class is shown in the hosted-scan row rather than disguised as a fixed destination list. Every such request still crosses the per-request method, resource-type, scheme, port, and private address policy described below.

What a hosted scan sends to your own site, which no capture on your machine can show you because it never crosses your wire:

• The routes you chose for the scan, fetched as ordinary GETs under the same SiteCMD identity a desktop scan sends, but from Cloudflare's network rather than from anyone's laptop. There is no fixed SiteCMD address to allowlist: the source address varies by the location that ran the scan
• A bounded set of probes about the entry route, each one a GET or a HEAD: the favicon and web app manifest the page declares, /privacy and /terms, a deliberately absent path to see how the site answers a 404, the page again with a foreign Origin header to test CORS reflection, the page again without following its redirects to trace the chain, the www variant of the hostname, a sweep of common redirect parameters on a short list of common paths to test for an open redirect, and a sample of the links the page points at, internal and external, to find the broken ones
• On a full profile, a fresh Cloudflare Browser Run context renders each route and can request public HTTPS scripts, stylesheets, images, fonts, XHR, and fetch resources from any host the page itself names. Chromium can request those resources concurrently. SiteCMD intercepts every request, fetches each bounded response through Cloudflare Workers public egress under the same URL and method policy, and fulfills it into the browser. Target hosts receive the SiteCMD identity, not Browser Run's automatic request headers. SiteCMD retains the resulting bounded browser facts, verdicts, and proxy-adjusted timing samples, not the rendered document or response bodies

And the bounds it runs under, which matter more than usual for the same reason:

• Any caller-selected scan target outside the connected, verified site's environment URL and canonical route scope. Browser subresources are page-controlled rather than caller-supplied and still have to pass the per-request public-HTTPS policy
• Response bodies, rendered DOM, or query strings into any store, log, trace, or error report: only derived verdicts and numeric timing samples survive the page step
• Any method but GET, HEAD, and the browser's own OPTIONS preflights, on your origin or any other, so that scanning your page can never become a way of operating it
• Any request over plain HTTP: the hosted address discipline refuses a non-HTTPS URL before it is fetched, which is why the check that asks whether http:// redirects is reported as unanswered from this vantage rather than graded

Operational calls, named and minimal

A small set of calls keeps the app licensed and up to date and resolves your dependencies. Each one sends only what it needs to do its job, never your code or scans, and every one is named in the table below.

Analytics and crash reports, off by default

Both are opt-in and stay off until you turn them on. When enabled, they send only anonymized, sanitized diagnostics, never your scans, source, or credentials. The table below lists exactly what each one carries.