IncludeSubDomains

Expanded Definition

IncludeSubDomains is the HSTS directive that tells a browser to treat the parent policy as applying to every child host under the registered domain. In practice, it is a boundary-setting control: once the directive is active, OWASP Non-Human Identity Top 10 is not the relevant lens unless the subdomains themselves expose machine-to-machine access paths or identity-bearing endpoints.

The main distinction is between protecting one web origin and asserting a wider trust zone. Without IncludeSubDomains, a domain can enforce HTTPS on the apex while leaving legacy or third-party subdomains outside the policy. With it, the policy becomes stricter but also less forgiving: any subdomain that is still reachable only by HTTP, or that cannot present a valid certificate, may fail for users. Guidance is straightforward here and not controversial: the directive is useful when subdomain hygiene is already mature, but it should not be treated as a cosmetic hardening toggle.

Examples and Use Cases

IncludeSubDomains commonly appears in deployment patterns where one security team owns the entire domain namespace and can verify that all hosts are ready for HTTPS enforcement.

• A SaaS platform enables it after confirming that marketing, status, and support subdomains all redirect cleanly to HTTPS.
• A bank uses it to reduce downgrade exposure across customer-facing and authentication subdomains that should never accept cleartext traffic.
• An engineering team delays it because a legacy helpdesk host still depends on HTTP and would break when the parent policy expands.
• A security group pairs it with certificate coverage checks so new subdomains are not launched outside the HTTPS baseline.

The tradeoff is operational, not conceptual. The directive raises assurance for users and browsers, but it also turns subdomain inventory, certificate management, and decommissioning discipline into prerequisites rather than optional housekeeping.

Security Implications

Misunderstanding IncludeSubDomains can create a false sense of protection. A parent domain may look hardened while an overlooked subdomain remains available over HTTP, leaving room for downgrade attacks, cookie exposure on legacy paths, or inconsistent transport enforcement across the brand footprint.

The other failure mode is self-inflicted outage. If a subdomain serves traffic without a valid certificate, or if DNS and hosting changes introduce an unmanaged host, browsers may block access or surface warnings that break user journeys. That is especially important for organisations with many delegated teams or third-party-managed subdomains, where the security control is only as reliable as the inventory behind it.

Practitioners should treat subdomain scope as an enforceable asset boundary. The common mistake is assuming the directive protects only the hosts people actively remember; in reality, it covers forgotten, inherited, or temporary subdomains too.

Domain and Governance Relevance

IncludeSubDomains matters most in web trust governance because it changes the scope of a transport-security promise. It is not an abstract hardening flag; it is a commitment that the domain owner can keep every subdomain inside the HTTPS envelope for as long as browsers remember the policy.

That makes ownership, certificate lifecycle, and subdomain review part of governance rather than ad hoc operations. In identity-heavy environments, the directive is especially relevant where subdomains host login flows, API endpoints, or machine-to-machine services that depend on browser trust or same-domain assumptions. The governance question is simple: can the organisation reliably account for every reachable subdomain before it tells browsers to enforce HTTPS everywhere?

For NHI-related services, the practical concern is not the label itself but the effect on service endpoints and token-bearing integrations. If a workload or agent depends on a subdomain that is not HTTPS-ready, the control can disrupt identity flows as easily as it improves them.