StateChangeOnGet [anti-pattern] v0.1.0

Routes that perform side effects — delete, transfer, subscribe, like, vote, fire-the-missiles — in response to a GET. Including 'click here to confirm' links that use GET, image-tag-triggered URLs, and admin actions exposed via clickable links.

Label

Mutating server state in response to a GET request

Why Bad

Any HTML on any page on the internet can issue a cross-origin GET — <img src=https://yourapp.com/admin/delete?id=42> — and the user's browser will attach their cookie if SameSite is not strict. CSRF tokens don't help if the route accepts GET; bookmarks, prefetchers, link-preview crawlers, and antivirus URL scanners may all silently fire the action.

Instead Do

    Restrict mutations to POST / PUT / PATCH / DELETE and require an
    anti-CSRF token. GET handlers must be safe and idempotent — read-only,
    no observable side effects (cache-warming reads are fine; state
    changes are not).

    For 'one-click confirm' email links (where a token in the URL must
    do something on click), make the page render a form and POST the
    confirmation, OR validate that the token is single-use and bound to
    one user-specific action.
  

StateChangeOnGet [anti-pattern] v0.1.0

Routes that perform side effects — delete, transfer, subscribe, like, vote, fire-the-missiles — in response to a GET. Including 'click here to confirm' links that use GET, image-tag-triggered URLs, and admin actions exposed via clickable links.

Label

Mutating server state in response to a GET request

Why Bad

Any HTML on any page on the internet can issue a cross-origin GET — <img src=https://yourapp.com/admin/delete?id=42> — and the user's browser will attach their cookie if SameSite is not strict. CSRF tokens don't help if the route accepts GET; bookmarks, prefetchers, link-preview crawlers, and antivirus URL scanners may all silently fire the action.

Instead Do

    Restrict mutations to POST / PUT / PATCH / DELETE and require an
    anti-CSRF token. GET handlers must be safe and idempotent — read-only,
    no observable side effects (cache-warming reads are fine; state
    changes are not).

    For 'one-click confirm' email links (where a token in the URL must
    do something on click), make the page render a form and POST the
    confirmation, OR validate that the token is single-use and bound to
    one user-specific action.
  

Label

Mutating server state in response to a GET request

Why Bad

Any HTML on any page on the internet can issue a cross-origin GET — <img src=https://yourapp.com/admin/delete?id=42> — and the user's browser will attach their cookie if SameSite is not strict. CSRF tokens don't help if the route accepts GET; bookmarks, prefetchers, link-preview crawlers, and antivirus URL scanners may all silently fire the action.

Instead Do

    Restrict mutations to POST / PUT / PATCH / DELETE and require an
    anti-CSRF token. GET handlers must be safe and idempotent — read-only,
    no observable side effects (cache-warming reads are fine; state
    changes are not).

    For 'one-click confirm' email links (where a token in the URL must
    do something on click), make the page render a form and POST the
    confirmation, OR validate that the token is single-use and bound to
    one user-specific action.