Time-of-Check, Time-of-Use race on origin

A Time-of-Check, Time-of-Use race on origin occurs when a page is validated at one moment and the script is executed later against a different page. In WebView, asynchronous callbacks, navigation changes, and persistent listeners can make the checked origin and the executed origin diverge.

Expanded Definition

Time-of-Check, Time-of-Use race on origin describes a security gap where code validates one page or origin, then later acts on a different origin because navigation or callback timing changed. In NHI and agentic browser contexts, the risk is not only what a script can do, but what page it is actually doing it on.

This pattern is common in WebView integrations, asynchronous event handlers, and persistent listeners that survive page transitions. The security question is whether the origin observed at validation time is still the origin at execution time. That distinction matters because origin-based trust decisions often gate access to cookies, tokens, storage, message handlers, and tool invocation. Guidance varies across vendors on how aggressively to re-check origin, but the safest interpretation is to treat origin as a volatile security attribute and validate immediately before use, not just once during setup. The NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it reinforces the need for access enforcement tied to current conditions, not stale assumptions.

The most common misapplication is assuming a one-time origin check remains valid after navigation, which occurs when developers bind privileged callbacks to long-lived views without revalidating the active document.

Examples and Use Cases

Implementing origin checks rigorously often introduces timing complexity, requiring teams to weigh safer revalidation against the risk of breaking legitimate asynchronous flows.

• A browser extension injects a listener into a trusted page, but the tab navigates before the callback fires, so the listener runs against an untrusted origin.
• An AI agent operating in a WebView validates a login page, then a redirect lands on a phishing page before the script completes its privileged action.
• A persistent message handler accepts commands from an origin that was trusted during setup, even though the frame has since been replaced by attacker-controlled content.
• A mobile app embeds a WebView for OAuth, but delayed UI events allow a later navigation to inherit capabilities intended only for the original authorization page.
• Attackers exploit page replacement during callback latency to cause a tool call or secret read to execute on the wrong document, a failure mode highlighted in the Ultimate Guide to NHIs when long-lived access paths are not tightly governed.

For browser-side threat modeling, the OWASP ecosystem and implementation guidance around current-origin enforcement are useful reference points, even though no single standard governs this exact race condition yet.

Why It Matters in NHI Security

In NHI security, this race condition can turn a normally constrained automation flow into an origin-confused privilege path. A script may appear to operate under approved context while actually executing after navigation into attacker-controlled content. That is especially dangerous when the page can reach secrets, service credentials, or agent tools.

The impact is amplified by the broader NHI exposure profile documented by NHI Mgmt Group: Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. A TOCTOU origin race can convert that exposure into an active compromise when the wrong page inherits a trusted execution path. Pairing current-origin validation with NIST SP 800-53 Rev 5 Security and Privacy Controls strengthens governance by forcing authorization decisions to reflect the live execution state.

Organisations typically encounter the consequence only after a redirect, frame swap, or callback delay exposes a secret or triggers an unintended action, at which point time-of-check, time-of-use race on origin becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Time-Of-Check/Time-Of-Use Flaw
• Should identity teams use just-in-time access for NHIs?
• When should organisations use just-in-time access for manufacturing identities?
• When should teams use just-in-time access for privileged actions?