Security
You are handing a tool access to the accounts that run your business. Here is exactly what it does with that access.
Last reviewed 2026-08-21
Observation only
Version 1 reads. It does not write. DomainOverseer requests read-only scopes wherever a provider offers them, and it never changes DNS records, nameservers, registrar settings, firewall or bot rules, mail routes, mailbox labels, deployments, or Search Console settings.
There is one place where the consent screen is broader than what we do. Google describes the Gmail label scope as permission to see and edit labels, and there is no narrower read-only option. We use only the list and get methods for labels, and the adapter is tested against an outbound method allowlist so a later change cannot start modifying a mailbox. We would rather tell you that plainly than let a consent screen say one thing while we imply another.
What we ask each provider for
- Cloudflare. Zone read, analytics read, DNS read, and, where you use them, Email Routing read scopes. Never zone write, DNS write, firewall write, or a Global API Key.
- Vercel. Read access to teams, projects, project domains, deployments, and Web Analytics.
- Google Search Console and Analytics. The read-only Search Console scope and the read-only Analytics scope. Nothing that can change a property or a report.
- Gmail, if you enable it. The label scope only, in a separate Google Cloud project and OAuth client from Search Console and Analytics. Message metadata and message content scopes are restricted by Google, remain switched off, and are not part of what we market.
How credentials are stored
Provider access and refresh tokens are encrypted with AES-256-GCM before they reach the database. Each ciphertext is bound to the exact workspace, record, provider, and secret column it belongs to, so a value copied anywhere else fails to decrypt rather than opening the wrong account. Keys are versioned, environment specific, and rotatable, and a preview or development key can never read production data.
Credentials are decrypted only inside server-side connector code. They are never placed in page data, job payloads, logs, or error reports. Disconnecting a provider deletes its stored credentials and, where the provider supports it, revokes the token.
Data we deliberately do not keep
- No raw visitor IP addresses.
- No cross-site visitor identity graph, session replay, heatmaps, or fingerprinting.
- No email bodies or attachments, on any plan, in any mode.
- No archived raw provider payloads.
- Security data is stored as aggregates by default rather than as a raw event log with addresses and user agents.
Outbound requests
Every check against a domain you add goes through one policy layer. Addresses are canonicalized before they are judged, so the unusual encodings that hide a private address do not get through. Loopback, private, link-local, carrier-grade NAT, metadata-service, multicast, and reserved ranges are refused for both IPv4 and IPv6. Redirects are never followed automatically: each hop is parsed, revalidated, and pinned to an approved address, which is what closes the window a DNS rebinding attack needs.
Account security
- Passwordless sign-in, so there is no password to leak or reuse.
- Optional two-step verification. When it is on, it gates every sign-in method, including links and one-time codes, not just some of them.
- Recovery codes shown once and stored only as hashes.
- Session list, remote revocation, and recent security activity.
- Reauthentication before ownership transfer, billing management, workspace deletion, and data export.
Tenancy
A workspace is a hard boundary. Every domain, connection, metric, job, signal, report, and billing record belongs to exactly one workspace, and every relationship between two records carries that workspace identifier as part of its database constraint. Application checks alone would not be enough, so a cross-workspace relationship is rejected by the database even through a direct insert.
Reporting a vulnerability
Write to security@domainoverseer.com with enough detail to reproduce the issue. We will acknowledge you, keep you updated while we work, and credit you if you would like that. Please do not run automated scanning against other customers or attempt to access data that is not yours.
Support hours: Monday to Friday, 09:00 to 17:00 Pacific Time