DNS / email · Check
Sensitive subdomain exposed — dev, staging, and admin hostnames on the public Internet
Subdomains named `dev.`, `staging.`, `test.`, `admin.`, `vpn.`, or similar are common targets because they often run less-hardened stacks than production. Confirm each one is intentional, restrict access (VPN, IP allowlists, or basic auth) for any non-production hosts, and apply the same TLS/auth rigor as production for anything that must stay public.
Real-world risk
Dev, staging, admin, or VPN hostnames on the public Internet are common targets and may run less-hardened stacks.
Fix steps (in order)
- Confirm each hostname is intentional; restrict access (VPN, allowlists) or take non-production hosts off the public DNS.
- Apply the same TLS, patching, and auth rigor as production for anything that stays public.
Topic explainer
DMARC, SPF, and DKIM explained: the email authentication trio →
A practical guide to email authentication: what SPF, DKIM, and DMARC each do, why all three are needed, and how to roll out a DMARC policy that actually blocks spoofed mail.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (dns_subdomain_sensitive) clears once the externally-observable signal is in place.