All lessons Leer en español

Security in depth · Unit 20 · Lesson 22 of 27

Cookies do not prove action intent

Review a cookie-based change without treating session recognition as proof of intent.

3 minreadyShort lesson

Helpful before thisWeb applications

See all lessons in this topic

After this lesson you can

  • Distinguish a validated workflow signal from authentication and resource authorization.

Recognizing a session and recognizing a protected workflow are different checks.

Cookies do not express a decision

For this lesson, the browser authenticates to an application using a session cookie that it attaches automatically when the applicable rules permit. The cookie helps identify the session. Its presence alone does not show that the person intended a particular change.

A CSRF token is an unpredictable value the server checks as part of protection against unwanted cross-site state-changing requests. Use the framework’s supported design, including its binding and validation rules. Merely displaying a token creates no enforcement.

Session recognition → Workflow protection → Authorized changeSession recognitionWorkflow protectionAuthorized change
Session recognition, workflow protection, and action permission remain separate. Passing these controls does not prove that a person understood the action.

Fictional address-change review

Assume a club’s account page changes a delivery address. The framework provides a session-bound token mechanism.

  • C1: The server recognizes the session and verifies that the account belongs to that person.
  • C2: The form contains the framework token, but the change handler’s token validation is disabled.
  • C3: The session cookie uses SameSite=Lax. The review calls this “proof the user intended the change.”

Match each claim to its control

C1 supports identity and resource permission. C2 leaves the intended workflow protection unenforced. Require the supported server validation before accepting the change, retaining C1. A missing or invalid token must not be treated as a successful check.

SameSite limits cookie delivery according to browser context and is useful as an additional layer; it does not validate the token or prove human intent. Even successful workflow protection cannot show that someone read or understood a confirmation screen. High-consequence changes may need an additional, clearly explained confirmation decision.

Review wording: Session and ownership checks pass; protected-workflow enforcement remains pending.

Terms you met

CSRF token

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

  1. Which change addresses the documented workflow gap?

    Show the answer

    Correct answer: Validate the framework’s CSRF protection on the server before accepting the change. This supplies the missing workflow check while preserving session recognition and ownership authorization.

Try it

  • WriteWrite a release condition for C1-C3 naming where token validation must occur, which existing checks remain necessary, and what no token can prove about human intent.
References