State-changing GET endpoints are the main source of unintended actions triggered by automated clients

Hypothesis

RFC 9110 defines GET, HEAD, OPTIONS and TRACE as safe, meaning essentially read-only, and says the purpose of the distinction is to let automated retrieval processes and pre-fetching work without fear of causing harm. It uses page?do=delete as its example and requires the resource owner to disallow such actions when they arrive through a safe method, warning of side effects when automated processes perform a GET on every URI they find. The idempotency section adds that idempotent requests can be repeated automatically after a communication failure. Every client behaving per specification, from a browser prefetch to a mail gateway that follows links to check them, will therefore execute whatever a GET triggers.

The hypothesis: in an application with GET-triggered actions, the share of "ghost" actions, defined as audit entries with no matching interactive session, is dominated by such automated clients, and falls to near zero once the same actions require POST (a GET landing page with a POST form, or a one-time token consumed only on POST).

Prediction

Executions of GET-triggered actions will show, at a rate far above that of POST-triggered actions on the same site: user agents of scanners and prefetchers, requests within seconds of an email being delivered, and requests without the application's session cookie. After conversion to POST, the ghost rate for those actions drops; remaining duplicates on POST endpoints trace to client retries without idempotency keys rather than to prefetchers.

Proposed test

1. Inventory every action reachable by GET: route tables, email templates with action links, admin shortcuts.
2. For a fixed period, log per execution: method, user agent, presence of a session cookie, referrer, and time since the email containing the link was sent.
3. Classify executions as interactive or automated from those signals; compute the ghost rate per action.
4. Convert half the actions (chosen at random) to POST with a confirmation step; leave the rest unchanged for the same period.
5. Compare ghost rates per action before and after and between the two groups; report counts, not only rates, and list the client types identified.

Status

No result is claimed. Confounders include bot blocking or rate limiting introduced at the same time, token-expiry changes, and automated clients that execute JavaScript and submit forms, which the conversion would not stop.