What Security Teams Should Monitor Across Every Company Domain

Security teams do not defend one website. They defend a changing set of apex domains, subdomains, redirects, login pages, campaign microsites, vendor-hosted pages, APIs, and edge configurations. A practical domain security monitoring checklist should combine asset discovery, configuration drift detection, and abuse visibility. That framing matches CISA's emphasis on asset discovery and vulnerability enumeration as core visibility activities (CISA BOD 23-01).

The goal is to know what exists, which controls are present, where controls have drifted, and which surfaces deserve faster review.

Inventory Every Public Domain and Subdomain

Start with ownership. Every monitored hostname should have a business owner, technical owner, expected purpose, environment, DNS provider, hosting provider, and review cadence. Include production domains, regional domains, documentation sites, status pages, marketing experiments, authentication endpoints, API hostnames, and domains delegated to agencies or SaaS vendors.

Forgotten subdomains are especially important because they often retain trust without receiving maintenance. OWASP's subdomain takeover guidance calls out shadow IT, abandoned proof-of-concepts, and stale DNS records as common causes of exposure (OWASP Subdomain Takeover Prevention Cheat Sheet). MDN describes subdomain takeover as a condition where an attacker gains control of a subdomain, with potential consequences including malicious content, login capture, and policy circumvention (MDN).

Exposed test environments belong in the same inventory. Staging, preview, QA, and demo hosts should not be treated as lower-risk because they are not linked from navigation. Monitor whether they require authentication, whether search indexing is disabled, whether secrets or debug output are exposed, and whether they share cookies, OAuth callbacks, or production identity providers.

Check Edge Controls and Browser Protections

For each domain, record whether traffic is consistently served through the expected CDN, reverse proxy, or web application firewall. Presence alone is not proof of protection, but absence or unexpected routing changes are useful signals. Monitor TLS configuration, certificate expiry, redirect behavior, and whether any public hostname has drifted away from the standard edge path.

Security headers should be part of the baseline. At minimum, review Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. OWASP explains how headers such as HSTS and CSP reduce common browser-side risks when configured appropriately (OWASP HTTP Headers Cheat Sheet). Track changes over time because header regressions often happen during framework migrations, CDN changes, or emergency releases.

Cookie settings should also be visible across domains. Session and authentication cookies should use Secure, HttpOnly, and appropriate SameSite settings, with tight domain scoping. A cookie scoped too broadly can turn a low-priority hostname into a path toward a higher-value application.

Monitor Bot and Login Protection as Part of EASM

Anti-bot visibility is one component of external attack surface management, not a standalone program. Security teams should know which domains have bot controls, which paths are protected, and whether those controls cover APIs, login forms, checkout flows, lead forms, search endpoints, and account recovery. OWASP's bot management guidance recommends mapping endpoints to automated threat patterns rather than applying one generic control everywhere (OWASP Bot Management and Anti-Automation Cheat Sheet).

Login protection deserves its own row in the checklist. Monitor MFA coverage, rate limiting, adaptive step-up, password reset behavior, account lockout thresholds, suspicious success rates, and credential stuffing alerts. OWASP defines credential stuffing as automated use of stolen credential pairs against login forms and recommends layered defenses rather than relying on one challenge or control (OWASP Credential Stuffing Prevention Cheat Sheet).

For each domain, ask: can we distinguish normal users, trusted automation, search crawlers, partner integrations, suspicious scrapers, and abusive login automation? BotScope helps keep domain-level bot and crawler visibility connected to the broader external attack surface view, so anti-bot work does not become isolated from inventory and control validation.

Review Third-Party Scripts and AI Crawler Controls

AI crawler controls now belong in the same external checklist. For public marketing pages, documentation, support articles, pricing pages, and research content, monitor robots.txt, relevant meta or X-Robots-Tag rules, and crawler traffic in logs. Google's robots documentation explains that robots.txt tells crawlers which URLs they may request, while Google's crawler documentation describes Google-Extended as a product token publishers can use to manage whether crawled content may be used for specified Gemini and Vertex AI uses (Google robots.txt, Google crawler docs).

Treat AI crawler controls as policy plus verification. Document the intended policy, confirm what each domain serves, and compare observed crawler behavior against it. The checklist is simple: know every domain, verify controls, watch for drift, and connect bot visibility to the rest of the attack surface.