Skip to content

GET-Action Security

GET-Action security starts by assuming URLs leak. Query strings can appear in browser history, server logs, analytics, referrers, caches, screenshots, and support tickets.

Security checklist

  1. Require an idempotency key and reject replay with conflicting parameters.
  2. Never include secrets, tokens, passwords, API keys, patient IDs, account identifiers, payment data, private messages, or regulated data in the query string.
  3. Use a matching POST endpoint for L2+ clients and all rich or sensitive actions.
  4. Require human consent for publication, repository writes, account changes, destructive actions, durable memory writes, financial actions, or regulated contexts.
  5. Apply strict rate limits, crawler protection, and abuse detection before action execution.
  6. Log public-safe audit evidence without storing raw secrets or private query material.
  7. Keep action endpoints out of public sitemap entries and search-index invitations.
  8. Return a review URL or blocker instead of executing ambiguous requests.

Reject examples

  • ?token=..., ?api_key=..., ?password=..., or bearer-like values.
  • Medical or regulated identifiers carried in URLs.
  • One-click destructive, payment, publication, or account-change URLs without a stronger reviewed path.

Safe default

When unsure, do the read-only part, return a human-readable review URL, and require POST JSON or human approval before execution.