YanoSecA browser may attach a stored session cookie when it sends a request, including some requests caused by another site. Cross-site request forgery, or CSRF, abuses that automatic authority to cause an unwanted action. The cookie identifies a session; it does not by itself show that the user intended the action.
The fictional edit policy requires both a login cookie and a matching CSRF token. Here the token is an unpredictable value tied to the session and included by the intended application page. The server checks it before changing data. SameSite is a cookie setting that limits cross-site sending. Those settings and origin checks can provide additional defenses, but this activity isolates the token rule.
Before you begin
- Recommended first
- Notes: scope, command, result, time, HTTP methods, headers, status codes, cookies, How a web app is put together, Same-origin policy, Cross-site scripting
- Estimated time
- 16 min reading, 12 min activity. Setup and optional practice may take longer.
- Where you work
- Use the fictional page source, requests and policy models printed here in any current desktop or mobile browser. No server, login, framed account page or socket connection is required.
- Without a lab
- Read each source fragment or model and predict its result in notes. Identify the boundary, the supporting fact and one limit, then compare with the activity rubric. This does not reproduce a browser exchange. Reading works without JavaScript. Checking requires JavaScript and a secure context; saving additionally requires usable browser storage.
After this lesson you can:
- Name the two values the edit policy requires.
- Apply the token-matching requirement to the copper-versus-silver guided request.
- Keep a state-changing action off a bare GET in the optional note.
01Example
The worked POST /notes/7 has a login cookie and matching token. The fresh guided POST /notes/12 instead supplies copper when the session expects silver.
POST /notes/7
Cookie present. CSRF token present and matches the session.
Both requirements are present, so the card applies the edit.02The cookie is only half
The worked request carries both required values. A request with an incorrect token still fails even though a token field is present: the server must compare the supplied value with the expected one. A cross-origin page generally cannot read a secret token from the protected page, which is why automatically attached cookies do not supply the same protection.
The trust boundary is an externally caused request becoming an authorized state change. Validate the token on the server using a supported CSRF mechanism, and avoid changes on safe GET requests. XSS in the application can undermine token defenses by acting inside the trusted page context. These printed models establish policy reasoning rather than actual cookie or browser behavior.
Require a second value from the session before an edit, because the browser may attach the login cookie by itself.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Cookie present.
met · PresentCSRF token present and matches the session.
met · Present and matches sessionBoth requirements supplied by this fictional card are present.
A login cookie alone is insufficient for this model's state change; matching the session token is a separate check.
Both requirements supplied by this fictional card are present.
Follow the explanation
- Both requirements supplied by this fictional card are present.
- The second condition must be checked separately; no edit is sent here.
Read every state and value
1. Both requirements supplied by this fictional card are present.
- Case
- both
- Conditions inspected
- Session cookie · Separate matching token
- Decision shown
- Yes
2. The second condition must be checked separately; no edit is sent here.
- Case
- cookie-only
- Conditions inspected
- Session cookie · Separate matching token
- Decision shown
- Yes
03Decide the activity request
Use this fresh activity: POST /notes/12 has a valid login cookie; its token is copper while the session expects silver. Compare the token values before deciding whether the edit may occur. The downloadable requests provide additional contrasts.
Edit policy for the owned notes app.
An edit is applied only when both requirements hold:
the login cookie for the caller
a supplied CSRF token matching the value expected for that caller's session
The cookie may be attached by the browser when the browser sends the request.
The token is a second value the intended page has to send.
A request caused by another site can carry the cookie and still lack the token.
Original fictional edit requests. No request was sent.
Worked request
POST /notes/7
Cookie: session=ada-session
CSRF token: present, matches the session
Decision: both policy conditions hold.
Fresh guided activity
POST /notes/12
Cookie: valid login cookie
Supplied token: copper
Expected session token: silver
Compare the two values before deciding whether the edit applies.
Additional checkpoint-style evidence, without a supplied decision
POST /notes/9
Cookie: session=ada-session
CSRF token: absent
- Write the cookie requirement and the token-matching requirement.
- Compare copper with the expected silver value. Does a present but different value satisfy matching?
- Rubric: the edit must remain unapplied because the supplied token does not match. Presence alone is insufficient.
- Stop at the printed model; no request or account operation is needed.
04Optional challenge
Explain why a GET should not apply this edit. The rubric is: a navigation can send a GET with the ambient cookie, and the edit belongs on a method the card treats as the change. About ten minutes.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Edit case A: new request matrixOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Apply a POST edit only if a valid login cookie is present and the supplied CSRF token matches that session’s expected value.
Expected token for this model session: violet.
P: valid cookie; token violet.
Q: no valid cookie; token violet.
R: valid cookie; token orange.
No request is sent.
Edit case B: independent omissionOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
POST edit; valid session cookie; no CSRF token supplied.
Policy: both valid session cookie and matching supplied token are required.
06Explain your evidence
Optional written self-check: explain one decision using the supplied case. No tool run is required.
Check your explanation: test session and token separately; compare exact token values; distinguish absent from mismatched; explain why a recognized session alone does not authorize the change and why GET should remain safe.
07Common mistakes
If any token seems sufficient, compare the actual values. A field can be present while failing the match.
If a login cookie seems to prove intent, distinguish recognizing a session from checking the intended action.
If you rely on the browser's reading restriction alone, remember that preventing a response read is different from preventing a state change.
References
- RFC 6265: HTTP State Management Mechanism
The introduction. The user agent may return a stored cookie. This lesson uses that as the ambient cookie.
- PortSwigger: CSRF
Explains this mechanism, its impact and defenses. Required reasoning uses the original evidence printed on this page.