September 2026 Summaries

A security engineering team replaced an unenforced device-fingerprinting system, which relied on request headers and GeoIP data but could neither reliably identify attackers nor avoid disrupting mobile and VPN users, with browser-generated proof-of-possession keys that bind sessions to non-extractable WebCrypto credentials. After login, the browser registers an ECDSA P-256 public key with the server and signs authenticated requests, preventing a stolen cookie alone from being used elsewhere, although copied browser profiles and live cross-site scripting attacks remain significant limitations. Implementing the system exposed practical issues including WebCrypto and Python signature-format differences, incomplete request coverage, replay risks from a five-minute timestamp window, OAuth route exemptions, CSRF-like logout vulnerabilities, and a path-handling bug that initially caused all proofs to fail. The team used account-level counting mode before enforcement to limit rollout risk, removed obsolete fingerprinting dependencies and a 63 MB GeoIP database, and added protections for sensitive navigation routes using Fetch Metadata headers. The author concludes that the custom mechanism resembles the DPoP standard and should eventually be replaced where possible by Chrome’s Device Bound Session Credentials, which uses hardware-backed keys and short-lived cookie refreshes without application-level signing code, though its current lack of Firefox and Safari support requires a transitional approach.

A dashboard exposed a brief cross-account display issue because its React Query cache used one constant sessionStorage key for every login within the same browser tab, allowing a newly signed-in user to see a previous user’s cached profile and organizations until fresh network data arrived. The problem became visible after a resilience improvement allowed the application to render available cached data during GitHub outages rather than remain on a loading screen. Instead of attempting to infer sign-outs from unreliable 401 responses, the team scoped cache keys to a value generated or assigned uniquely at login, such as a request-signing session identifier, so each login reads a separate cache entry. This approach does not remove old data or protect against scripts already running on the same origin, and impersonation flows require explicit cache clearing because they intentionally retain a shared server session. Implementing the solution also introduced asynchronous IndexedDB timing risks, storage-eviction edge cases, and failure handling that expanded the initial small change substantially. The account emphasizes testing isolation by deliberately disabling the scoping mechanism and recommends that applications persisting browser caches inspect whether their storage keys are tied to the data owner rather than relying on detecting when cached data becomes stale.