Postmortem: Why Hardening One Code Path Does Not Harden All Code Paths

TLDR

During a formal security audit against 27 core authentication requirements, we uncovered 7 distinct security defects across our codebase. While none were catastrophic breaches, 6 of the 7 shared the exact same root cause: when we originally hardened our primary auth implementation, secondary backup proxies, shared UI components, and fallback bridge scripts were left untouched.

Surface Area	Identified Vulnerability	Root Cause	Architectural Remediation
Backup Proxy	Secret in URL (?secret=Y)	Cloned from legacy draft prior to primary hardening	Migrated to Authorization: Bearer header
Session Cleanup	Zombie HttpOnly cookie post-logout	Sign-out cleared localStorage but omitted server call	Added server endpoint trigger setting Max-Age=0
Bridge Scripts	Wildcard postMessage('*') on 9 sites	Secondary gate scripts omitted origin check	Restricted target origin to window.location.origin
Shared Web Comp	Missing OAuth prompt parameter	Component predated primary modal fix	Added prompt: 'select_account' / login

---

Hardening a single path leaves legacy code vulnerable

When engineering teams refactor or harden a critical auth workflow, we usually focus on the primary path: the main modal, the primary sign-in page, or the active API handler. We review the changes, merge the PR, and mark the ticket complete.

The underlying problem is that secondary code paths (such as legacy backup proxies, fallback web components, and helper utilities) continue shipping quietly alongside the primary path. Because they pass basic functional tests, they create a false sense of security while keeping vulnerabilities active in production.

---

Secondary endpoints bypass primary security controls

Our audit revealed 7 distinct secondary-path failures:

      7 Audited Security Defects (Secondary Paths)
      ├── [Backup Proxy] ── URL credential leak (?secret=Y)
      ├── [Session Cleanup] ── Zombie HttpOnly cookie post-logout
      ├── [Bridge Scripts] ── Wildcard postMessage('*')
      ├── [Session Endpoint] ── Un-rate-limited access
      ├── [Edge Workers] ── Missing Strict-Transport-Security (HSTS)
      ├── [Sign-in Surface] ── Account enumeration via error strings
      └── [Web Components] ── Outdated OAuth parameters (missing prompt)

1. Polling secret leaking into URLs: While our primary polling proxy transmitted bearer tokens via Authorization headers, a secondary backup proxy passed secrets as query parameters (?secret=Y), exposing them to server access logs and browser histories.
2. Zombie session cookies on logout: The primary client-side sign-out cleared localStorage but failed to trigger a server-side endpoint request, leaving HttpOnly session cookies active for up to an hour.
3. Wildcard postMessage call sites: While primary shell-to-tool communications validated origins via window.location.origin, 9 secondary fallback and bridge scripts used window.parent.postMessage(payload, '*').
4. Un-rate-limited session endpoints: The edge endpoint setting HttpOnly session cookies lacked per-IP rate limiting, allowing unthrottled requests.
5. Missing HSTS headers on edge workers: While HTML responses included Strict-Transport-Security, Cloudflare Function edge responses omitted the header.
6. Account enumeration via raw error strings: Two auxiliary sign-in surfaces output raw identity provider error messages (for example, differentiating "wrong password" from "user not found").
7. Outdated shared web components: While the primary modal included prompt: 'select_account', a shared web component written earlier was never updated, allowing silent session inheritance on shared machines.

---

Centralized utilities enforce uniform security invariants

We resolved all 7 findings by applying standardized fixes across every surface:

// Fix 1 & 3: Standardize origin validation and bearer headers
function securePostMessage(targetWindow, payload) {
  targetWindow.postMessage(payload, window.location.origin);
}
// Fix 2: Force server cookie expiration on logout async function terminateSession() {   await fetch('/api/auth/session', {     method: 'POST',     headers: { 'Content-Type': 'application/json' },     body: JSON.stringify({ action: 'clear' }),   });   localStorage.clear(); }

In addition, core security invariants like PKCE OAuth, HttpOnly session cookies, OS Keychain storage, and AES-GCM token encryption held strong throughout the audit.

Rule of thumb: Auditing one path is not the same as auditing all paths. When hardening any security-sensitive pattern, grep your entire repository for all matching call sites before closing your pull request.