Preflight Request

A preflight request is an OPTIONS call the browser sends before some cross-origin requests to ask whether the real request is allowed. The server must answer with the correct methods, headers, and origin policy, or the browser blocks the actual request before it is sent.

Expanded Definition

A preflight request is the browser’s permission check for certain cross-origin operations, usually triggered when a request uses non-simple methods, custom headers, or credentials. It is not the business request itself. The browser sends an OPTIONS probe first, then evaluates the response headers before deciding whether to continue.

In web security terms, preflight sits at the boundary between browser policy and server policy. The server must clearly state which origins, methods, and headers are allowed, and the browser enforces that decision before any sensitive payload moves across the network. The standards basis for this behavior is defined by the IETF Fetch model and related CORS processing rules, while operational guidance on how to manage the resulting access boundaries maps well to NIST Cybersecurity Framework 2.0.

Definitions are stable at the browser layer, but implementation patterns vary across vendors, frameworks, and API gateways. In NHI and Agentic AI environments, preflight often becomes part of the control plane that protects APIs used by agents, service accounts, and browser-based management consoles. The most common misapplication is treating a failed preflight as an application bug, which occurs when engineers debug the endpoint without first checking origin, method, and header policy.

Examples and Use Cases

Implementing preflight rigorously often introduces extra latency and configuration overhead, requiring organisations to weigh tighter cross-origin control against developer convenience and simpler API access.

• A browser app sends a JSON PUT request with a custom Authorization header, so the browser issues a preflight before the actual request is allowed.
• An internal dashboard calls an API on a different subdomain, and the gateway must return precise CORS headers or the browser blocks the call even though the backend route exists.
• An AI Agent interface uses browser-mediated requests to invoke tools, and preflight determines whether the tool endpoint can be reached from the approved origin.
• A secrets management console is embedded in a web portal, and strict origin policy prevents the portal from becoming a generic relay for cross-site credential access.
• An organisation reviews cross-origin failures against the broader NHI lifecycle described in the Ultimate Guide to NHIs to ensure the browser policy matches identity governance.

For API teams, the most useful reference point is the browser’s enforcement model rather than the application framework’s route logic. The preflight exchange only works if the response is aligned with the intended cross-origin relationship, which is why policy design should be tested alongside general web security guidance from the NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Preflight matters because it often becomes the first visible control failure when identities, secrets, and browser-based administration paths are connected. If the browser cannot confirm the server’s policy, the request stops early, which is helpful for containment but can also mask deeper misconfiguration in origin handling, header allowlists, or credential exposure. In NHI environments, that can affect service dashboards, token exchange flows, and agent control surfaces.

The operational stakes are high: NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes browser-exposed management paths especially sensitive when cross-origin policy is loose or inconsistent. That risk context is explained in the Ultimate Guide to NHIs, and it reinforces why access boundaries should be reviewed through a framework like NIST Cybersecurity Framework 2.0.

Organisations typically encounter preflight-related misconfigurations only after a blocked deployment, broken API integration, or unexpected browser denial, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between network trust and request-level identity trust?
• Why do access-request workflows matter for NHI governance?
• How should organisations use AI in access request approval without weakening control?
• What is the difference between access request automation and access governance?