Security

Observation only, with one exception you choose

DomainOverseer reads. It 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 or folders, deployments, or Search Console settings.

The exception is sending a message you wrote and pressed send on, from a mailbox you connected on purpose. That is the only thing in the product that changes anything outside it. It is not a side effect of reading: both mailbox connectors run through a transport that permits a fixed list of provider endpoints, of which exactly one per provider sends a message. A call to anything else fails before a request leaves, and the tests assert that the endpoints which would move, delete, relabel, or mark a message read are unreachable.

There is one place where a 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. 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

• C
  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.

• V
  Vercel

  Read access to teams, projects, project domains, deployments, and Web Analytics.

• G
  Google Search Console

  The read-only Search Console scope only. Nothing that can change a property or a report. Google Analytics is not requested.

• G
  Gmail, if you connect a mailbox

  Read and send, plus labels, in a separate Google Cloud project and OAuth client from Search Console. Not the modify scope, and not full account access: the send scope can only send, and cannot read, list, or delete. These are restricted Google scopes, so the connector stays switched off until Google verification and an independent security assessment are complete.

• M
  Microsoft 365 or Outlook, if you connect a mailbox

  Delegated Mail.Read, Mail.Send, and the minimum needed to learn which mailbox you authorized. Never Mail.ReadWrite, and nothing that reaches the rest of a directory.

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