Remove ?token= deletion-token path (#143)

The deletion token was accepted via the ?token= query parameter on both
DELETE /api/pastes/{id} and /redeem, and round-tripped through the paste
URL after creation. URL-carried bearer secrets leak into reverse-proxy
access logs and browser history.

- API: deletion tokens are now accepted only via the Authorization header
  (Bearer/Token/bare); query params are ignored on both endpoints
- Web create flow: token moves to the browser via a short-lived tok_<id>
  HttpOnly cookie instead of the redirect URL; the paste view reads it
  from the cookie, never from ?token=
- Web view: the delete button calls redeem() which takes the token from
  sessionStorage and sends it as an Authorization header
- Tests: correct token in query must be rejected (403/400); header path
  still deletes/redeems; extraction unit cases updated

Fixes #143
This commit is contained in:
fen
2026-09-10 08:37:07 -05:00
parent b0a58d6ca5
commit d7b51f02b6
7 changed files with 81 additions and 29 deletions
+7 -1
View File
@@ -310,7 +310,13 @@ func (h *Handlers) HandlePasteView(w http.ResponseWriter, r *http.Request) {
}
justCreated := r.URL.Query().Get("created") == "1"
token := r.URL.Query().Get("token")
// #143: the deletion token is no longer round-tripped through the URL
// (?token= leaks into access logs and history). The create flow sets a
// short-lived tok_<id> cookie; the paste view reads it once from there.
token := ""
if c, err := r.Cookie("tok_" + row.ID); err == nil {
token = c.Value
}
if justCreated && token != "" {
// one-time display of the deletion token via the created banner
http.SetCookie(w, &http.Cookie{Name: "tok_" + row.ID, Value: token, Path: "/", MaxAge: 60, HttpOnly: true, SameSite: http.SameSiteLaxMode})