Cross-Site Request Forgery

Expanded Definition

Cross-site request forgery, or CSRF, is an attack that causes a browser already holding valid authentication context to submit an unwanted request. The server sees a legitimate session, so the request can look authorized unless the application verifies intent. In NHI and IAM workflows, this matters when browser-based admin consoles, token refresh endpoints, or session renewal flows accept requests solely because cookies are present.

Definitions vary across vendors on whether CSRF is primarily a web application flaw or an identity-layer abuse pattern, but the operational reality is the same: the attacker exploits trust in the browser, not knowledge of the secret. That is why CSRF controls often complement, rather than replace, broader session and token protections described in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

The most common misapplication is assuming a valid login session alone proves intent, which occurs when state-changing requests are accepted without anti-CSRF tokens or origin validation.

Examples and Use Cases

Implementing CSRF defenses rigorously often introduces friction in browser-based workflows, requiring organisations to weigh stronger request validation against added complexity in front-end and session design.

• An administrator opens a cloud console in one tab and visits a malicious page in another, which silently submits a form that changes NHI permissions if the console relies only on cookies.
• A service portal uses cookie-backed refresh for a delegated session, and an attacker forces an unintended token renewal that prolongs access after a user should have been signed out.
• An internal approval workflow for secret rotation is exposed through a browser app, and a forged request triggers an action without the user’s deliberate approval.
• A developer documentation site includes a state-changing endpoint with no token check, allowing browser-based misuse even though the API key itself is never revealed.

In practice, teams compare CSRF protections with other browser trust controls, especially when aligning application behavior to the NIST Cybersecurity Framework 2.0. For a broader NHI context, the Ultimate Guide to NHIs is useful when browser sessions sit alongside machine identities, delegated access, and secret lifecycle controls.

Why It Matters in NHI Security

CSRF becomes especially dangerous in environments where browser-based administration touches non-human identities, because a forged request can rotate credentials, widen privileges, or alter policy without exposing the underlying secret. That is why NHI programs treat request integrity as part of identity governance, not just application hardening. The NHI risk picture is severe: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which makes any unintended state change more consequential.

Well-designed programs pair anti-CSRF tokens, same-site cookie settings, origin checks, and step-up validation for sensitive actions. These protections fit naturally within zero trust thinking and least-privilege governance, as reflected in the NIST Cybersecurity Framework 2.0. The operational lesson is that session authenticity is not the same as request legitimacy.

Organisations typically encounter CSRF as a root cause only after an unexpected privilege change, token renewal, or administrative action is traced back to a user’s browser session, at which point the control gap becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• What is the difference between network trust and request-level identity trust?
• What is the difference between PIM and cross-cloud privilege governance?
• Why do cross-domain attacks create more risk than single-domain intrusions?