A login cross-site request forgery is an attack that tricks a user into completing sign-in against an account the attacker controls. The result is not credential theft, but a misbound session that can be used for data exposure, manipulation, or later abuse.
Expanded Definition
Login CSRF is a session-binding attack: the victim is not tricked into revealing a password, but into authenticating to an account chosen by the attacker. That creates a valid session that belongs to the wrong principal, which can quietly redirect actions, telemetry, and access decisions.
Definitions vary across vendors because some materials group login CSRF with broader cross-site request forgery, while others treat it as a separate authentication-layer flaw. In practice, the term is most useful when a site accepts a sign-in flow without strong anti-automation checks, origin validation, or state binding. The risk is especially relevant in browser-based SSO, embedded login widgets, and older application flows that do not fully align with modern guidance in the NIST Cybersecurity Framework 2.0.
For NHI and agentic systems, the concern extends beyond human user accounts. A misbound browser session can place an operator inside the wrong tenant, surface the wrong secrets, or authorize downstream automation against unintended resources. The most common misapplication is assuming any successful sign-in proves user intent, which occurs when the application validates credentials but not the authenticity of the login request context.
Examples and Use Cases
Implementing login flows rigorously often introduces friction, requiring organisations to weigh user convenience against stronger request validation and session integrity.
- A victim visits a malicious page that silently posts a sign-in request, causing the application to create a session for an attacker-controlled account.
- An SSO portal accepts cross-site login initiation without checking request origin, allowing the browser to bind the user to the wrong identity.
- A developer embeds a third-party authentication widget but fails to bind state to the browser session, creating an opening for session confusion during callback handling.
- An operations console used by service teams authenticates correctly, but the browser is already logged into a different tenant, exposing configuration and NHI material in the wrong environment. Guidance in the Ultimate Guide to NHIs shows how weak visibility and overbroad access compound this kind of mistake.
- A security team hardens csrf protection on state-changing forms but leaves the login endpoint exempt, assuming authentication endpoints are never part of the attack path, contrary to the threat modeling emphasis in NIST Cybersecurity Framework 2.0.
In each case, the failure is not stolen credentials. The problem is that the browser is persuaded to establish trust on behalf of the wrong account, which later affects data access, audit trails, and privileged actions.
Why It Matters in NHI Security
Login CSRF matters in NHI security because misbound sessions can expose service consoles, API gateways, secret stores, and automation dashboards to the wrong identity context. Once a session is established incorrectly, downstream controls such as RBAC, PAM, and JIT may still function exactly as designed, but against the wrong account or tenant.
This is one reason NHI governance has to include session integrity, not just secret hygiene. NHI Mgmt Group notes that Ultimate Guide to NHIs reports 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, showing how identity errors quickly become operational incidents. The broader control model in NIST Cybersecurity Framework 2.0 also reinforces the need to verify access context, not just authentication success.
For agentic AI systems, the stakes rise further because an AI Agent may inherit the wrong session and use tool access automatically. Organisations typically encounter the consequence only after an unexpected data exposure, tenant crossover, or unauthorized workflow execution, at which point login CSRF becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers auth/session integrity issues that let attackers bind the wrong identity to a browser session. |
| NIST CSF 2.0 | PR.AC-7 | Addresses authentication and authorization conditions that must align with the intended user context. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of identity and session context, not blind trust after login. |
Validate request context during sign-in and ensure access decisions are tied to the right identity and session.
