Security: Replace query-string update token and state-changing GET updater

[fvent01]

Finding

frontend/public/update.php authorizes HTTP updates with ?token=... and immediately performs a database backup and schema migrations during that GET request.

Risk

Secrets in URLs can leak through browser history, bookmarks, access logs, screenshots, monitoring systems, copied links, and referrer behavior. Once leaked, the token grants access to an administrative migration endpoint. Performing state changes over GET also makes accidental execution, link scanning, prefetching, and replay more likely. The JSON response can include migration output and absolute backup paths.

Evidence

• The updater reads $_GET['token'] and compares it to UPDATE_SECRET_TOKEN.
• A successful authorized GET proceeds directly into backup creation and exec() of the migration runner.
• The response includes command output and the generated backup path.

Recommended remediation

• Prefer CLI-only updates.
• If HTTP updates remain, require an authenticated administrator session plus CSRF protection.
• Use POST for every state-changing update action.
• Never place administrative secrets in URLs; use a protected header or one-time form capability.
• Add short expiry, single-use behavior, and audit logging for any emergency update capability.
• Return generic browser responses and keep detailed paths/command output in restricted logs.
• Add Cache-Control: no-store to all update responses.

Acceptance criteria

• GET requests can never run backups or migrations.
• Update authorization secrets never appear in URLs.
• Browser-triggered updates require admin authentication and CSRF protection, or the endpoint is CLI-only.
• Detailed migration output and filesystem paths are not returned to remote clients.
• Tests cover unauthorized GET, replayed token, CSRF, expired capability, and successful CLI update.

Priority

P0 — administrative migration endpoint and secret exposure.