It's worth noting that in order to exploit this issue the following would all need to be true:
A user is running a copy of Datasette protected by a cookie-based authentication plugin AND configured with at least one writable canned query
An attacker is in control of a URL that could concievably be returned on a page that is displayed as the result of submitting a read-only canned query
An authenticated user of that Datasette instance, who is running a browser that doesn't support the SameSite=lax cookie parameter (which is widely supported by modern browsers), submits the read-only canned query form and then clicks a link to the attacker's off-site page, exposing their CSRFToken in the attacker's HTTP referer logs
The attacker then tricks that user into visiting their own malicious web page which includes a POST form that auto-submits against the writable canned query that the attacker wishes to exploit, including the CSRF token as a hidden field
The attacker would need full knowledge of the URL and form layout of the Datasette instance that they are exploiting.