What happens when certificate pinning or HSTS is missing in a web application?

Without HSTS, attackers can attempt SSL stripping and push users toward insecure HTTP sessions. Without certificate pinning, a forged certificate from a compromised or malicious trust chain is more likely to succeed. In both cases, the attacker can position themselves between the user and server, then read or alter traffic without immediate browser warnings.

Why Missing Pinning or HSTS Changes the Attack Surface

When a web application omits certificate pinning or HSTS, it weakens the browser’s ability to confirm that the user is really talking to the intended service over a protected channel. That matters because transport security is not only about encryption in transit; it is also about resisting downgrade and trust abuse. HSTS helps prevent an attacker from steering a session into HTTP, while pinning reduces the chance that a forged certificate will be accepted in a trusted-looking path. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful background for understanding why strong transport protections are treated as part of a broader control environment, not as optional hardening.

In practice, many teams discover the gap only after a proxy, captive portal, enterprise TLS inspection, or malicious Wi-Fi path has already influenced the session, rather than through intentional testing.

How the Failure Shows Up in Real Traffic

HSTS changes browser behaviour before the request is sent. Once a site is known to enforce HTTPS, the browser should stop attempting plain HTTP for that host, which removes one of the easiest downgrade paths. Without it, an attacker who can influence the network path may try SSL stripping or similar redirection tricks so the first contact, or a later revisit, happens over HTTP instead of HTTPS. The user may still see a normal page, but the session is no longer protected against interception or modification.

Certificate pinning addresses a different weakness. It narrows which certificate or public key the application will trust, making it harder for an attacker to rely on a rogue CA, a compromised intermediary, or a locally installed trust anchor. That is why pinning is often discussed in the context of high-value web applications, mobile clients, and sensitive admin portals. The control is strongest when the application can reliably know the expected key material and has a disciplined rotation process.

HSTS protects against protocol downgrade and first-hop HTTP exposure.
Pinning protects against acceptance of an unexpected but otherwise valid-looking certificate.
Both controls reduce the attacker’s ability to sit between the client and server without obvious warnings.

This guidance breaks down where the application must support legacy endpoints, shared infrastructure, or certificate rotation practices that are not tightly controlled.

Common Edge Cases and Where the Trade-Offs Matter

Tighter transport trust usually increases operational rigidity, so organisations need to balance interception resistance against recovery and change management.

One edge case is that certificate pinning can create an availability problem if the pinned key changes and the application has no safe update path. That is a deployment risk, not a theoretical one: if pinning is too rigid, legitimate users can be locked out during rotation or emergency certificate replacement. Another edge case is enterprise TLS inspection. Some organisations intentionally terminate and re-encrypt traffic at controlled gateways, which can conflict with strict pinning and makes browser or client policy more complicated. There is no single universal rule here, so the right answer depends on whether the application is expected to operate in a managed inspection environment.

HSTS has its own nuance. It is valuable when users might arrive through bookmarks, old links, or typed hostnames, because it prevents accidental fallback to HTTP after the site has been learned by the browser. But HSTS does not fix a site that already serves insecure assets, mixed content, or weak application logic. It also does not help if the very first connection is intercepted before the policy is established, which is why preload and consistent HTTPS deployment matter. The practical test is whether the browser can be made to trust the secure path by default, without relying on user judgement.

Risk and Threat Considerations

Missing HSTS or pinning creates a network interception risk because the application becomes easier to downgrade, impersonate, or place behind a forged trust path. The main exposure is confidentiality and integrity loss during session establishment, where the attacker benefits most from the user’s initial trust in the browser or client.

Failure mechanism: An attacker who can influence routing, DNS, Wi-Fi, proxying, or trust stores can exploit absent HSTS to keep traffic on HTTP or exploit absent pinning to present a certificate that is technically trusted by the local chain, then relay or alter traffic in transit.

Impact: Credentials, session tokens, and sensitive application data can be exposed or modified, and the user may have little immediate indication that the secure channel was weakened or impersonated.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.DS-2 — Data-in-Transit Security	Missing HSTS or pinning weakens protection for data in transit.
	PR.PT-3 — Least Functionality	Blocking HTTP fallback and limiting insecure pathways reduces attack surface.
Recommendation — Enforce transport protections for web sessions and prevent downgrade paths. Remove plaintext fallback paths and limit insecure transport options.
CIS Controls v8	13 — Network Monitoring and Defense	Transport downgrade and MITM exposure are network defense concerns.
	6 — Access Control Management	Pinning and trust validation affect which certificate paths are accepted.
Recommendation — Monitor for downgrade attempts and TLS interception on user-facing traffic. Restrict trust paths and remove unnecessary acceptance of alternate certificates.
MITRE ATT&CK	T1557 — Adversary-in-the-Middle	The question centers on man-in-the-middle interception enabled by weak trust controls.
Recommendation — Map intercepted sessions to T1557 and hunt for interception conditions.

Practitioner Guidance

What to prioritise: Treat HSTS as the baseline control for browser-facing web properties that should never support plaintext access, and reserve pinning for applications where the trust boundary is unusually sensitive and certificate provenance is tightly managed. Do not treat pinning as a substitute for correct HTTPS deployment.

What to verify: Confirm that every user-facing hostname either enforces HTTPS consistently or is intentionally excluded, that redirects do not allow a downgrade window, and that any pinning strategy has a tested recovery path for certificate renewal, revocation, and emergency key replacement.

Common mistake: Teams often enable one control and assume the other is unnecessary. In reality, HSTS and pinning address different failure modes, so the more important question is which downgrade or trust-abuse path remains open after the first control is in place.

Practitioner takeaway: Missing HSTS is mainly a downgrade problem, while missing pinning is mainly a trust-abuse problem, and mature teams design for both the normal browser path and the messy realities of certificate rotation.