flawopen.com/CSRF/GET requests
The real fix is different: a GET request should never perform a state-changing action in the first place. If that rule is followed, the question of CSRF-protecting GET mostly stops applying — CSRF tokens are needed for the state-changing POST/PUT/DELETE requests instead.
GET requests are trivially forgeable by design — a plain <img src="..."> tag, a prefetch, or a link preview can trigger one with no attacker infrastructure at all, and browsers, proxies, and crawlers all assume GET requests are safe to trigger without user intent (idempotent, no side effects). Using GET for something like "delete this item" means literally any embedded image tag anywhere on the internet can trigger deletion for a logged-in user — this is a design mistake independent of whether CSRF tokens exist.
As a stopgap, a CSRF token check can be added to that GET endpoint — but it's treating a symptom; migrating the action to a proper POST/PUT/DELETE method is the actual fix.