Cross-site request forgery exploits the way a browser automatically includes authentication material, commonly cookies, with a request. A malicious page can cause the browser to send a request to another site. When the receiving application cannot distinguish that request from one the user intended, it may change data or trigger an operation under the user's identity.
The conditions that make CSRF possible
The attack requires an authenticated action, credentials that the browser attaches automatically, and a request that another origin can cause. The action also needs a predictable shape. The attacker does not need to read the response for the unwanted change to succeed.
An audit of vibe-coded software therefore looks beyond the login screen. Authentication can correctly identify the session while the application still lacks evidence that the user initiated a particular request.
| Condition | Audit question | Relevant control |
|---|---|---|
| Ambient credentials | Does the browser attach the session automatically? | Cookie and session design |
| State change | Can the request create, update, delete, or trigger work? | Method and route review |
| Cross-origin trigger | Can another site cause the request? | Origin checks and browser policy |
| Predictable request | Can the attacker construct required fields? | Anti-CSRF token or re-authentication |
Tokens, origins, and cookie policy
An anti-CSRF token binds a state-changing request to a value another site cannot supply. Origin or referrer checks can provide additional evidence about where the request began. Cookie SameSite settings restrict when browsers send cookies across site boundaries. These controls have different coverage, so the audit checks how they work together for the application's clients and authentication model.
Requests that use an authorization header populated deliberately by application code often have a different exposure from cookie-authenticated requests. That difference must be verified in the actual client and server flow. A label such as “API” does not decide whether CSRF applies.
What the audit inspects
Reviewers inventory state-changing operations across the attack surface:
- Methods and routes: Confirm that read-like requests do not change state.
- Session transport: Identify cookies and other credentials attached by the browser.
- Request proof: Locate tokens, origin validation, or deliberate re-authentication.
- Alternate formats: Check forms, JSON endpoints, uploads, and method overrides.
- Sensitive actions: Give extra attention to account, permission, payment, export, and integration changes.
Verification follows the real client
The test must reproduce how a browser sends the production request, including cookie attributes, redirects, content types, and proxy behaviour. A server-side unit test that supplies a valid token proves the accepted path, but it does not prove that a cross-origin request is rejected.
Cross-site request forgery is separate from cross-site scripting. One abuses an authenticated request; the other executes untrusted code in the trusted page. The controls and test evidence remain distinct even when both concern browser boundaries. Preserving those distinctions is part of the disciplined review described in vibe coding versus agentic engineering.
