Direct answer
Cross-site request forgery (CSRF) can cause a user's browser to submit an unintended authenticated action. Assess state-changing endpoints, how the browser supplies credentials, and whether the server validates an appropriate anti-CSRF control before applying the change.
Inventory actions and credentials
List account changes, invitations, exports, and other actions that affect state. Identify whether credentials are automatically supplied by the browser or explicitly attached by application code. Check whether any nominally read-only request performs a write.
- Use reversible changes in a disposable account.
- Record the method, content type, and credential mechanism.
- Include normal forms as well as JavaScript-driven actions.
Review server validation
Framework CSRF protections, request tokens, origin checks, and cookie settings can contribute to protection. A token present in the request is not evidence that the server validates it. Test approved cases with missing or mismatched controls and verify the state did not change.
Reference: OWASP Cross-Site Request Forgery Prevention Cheat Sheet.
Confirm the browser path safely
Use an origin and account you control to evaluate the candidate browser interaction. Observe whether the browser sends the relevant cookies and whether the server accepts the harmless action. An HTTP client that manually attaches credentials cannot reproduce all browser restrictions.
- Verify the resulting application state, not only the status code.
- Restore the test account's setting after confirmation.
- Record blocked requests and their rejection reason.
Consider same-site boundaries
SameSite is defined around sites rather than individual origins. A sibling subdomain may belong to the same site even when it is controlled differently. Review untrusted subdomain hosting and legitimate cross-site flows when choosing controls, then retest normal sign-in and payment redirects.
Reference: OWASP Cross-Site Request Forgery Prevention Cheat Sheet.
Assessment limits
The absence of a visible CSRF token is not proof of vulnerability. Other validated controls or credential models may prevent the browser path. State changes must be harmless, reversible, and inside the agreed test scope.
Frequently asked questions
Is SameSite always enough to prevent CSRF?
Its protection depends on cookie settings, endpoint behavior, and the application's site boundaries. Evaluate the complete request path instead of assuming one attribute covers every action.
Can GET requests have a CSRF risk?
If a GET request changes state, browser navigation can create a relevant request path. Identify and repair state-changing behavior on methods intended for safe reads.
Does a rejected request prove the fix worked?
Check that the intended state remained unchanged and a valid request still succeeds. An error response alone can hide an action that already ran.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.