My static site was serving my internal docs

An engineer discovered that a production static site was serving an internal 150KB engineering handoff containing an admin query-string that skipped checkout, a documented schema bug that let clients create paid-looking accounts, and full database identifiers and history. The host’s build output directory was the repository root, so every committed file - including dot-directories like editor configs and GitHub workflows - became public; files only absent from the published site were those never committed (e.g., items in .gitignore). Attempts to remove the files and purge caches failed because the stale copy lived in the host’s edge asset tier, not the zone cache: headers showed cf-cache-status: DYNAMIC alongside an age and s-maxage that belonged to a different layer, and the platform’s default domain returned the updated content while the custom domain still served the old file.

Diagnosis and remediation focused on correct checks and an effective edge control. A cache-busted request reveals whether origin content is updated; plain requests reveal what visitors see. The exposure was closed by an edge firewall rule that blocks specific paths before cache lookup and by fixing the server-side schema hole (rotating the client-visible admin token alone would not have helped because the value was in client-side source). Recommended practices include ensuring build output isn’t the repo root, confirming removals with plain requests, using edge rules for cached content, and asking whether leaked values were ever truly secret.