The Security of Ephemeral Pages

Summary

I built a little webapp, or micro-service, depending on how you like to think about it. Because of what it does, security was never an afterthought; it was a genuine concern from the start. The surface area for abuse is real: an app that accepts and serves arbitrary HTML from the public internet is exactly the kind of thing that attracts unwanted attention. After the initial development and design phases were complete, I shifted focus to a structured security review. I have a security agent skill that I have been refining, and this felt like a good opportunity to put it to the test. I asked Codex to review the application using the skill as a reference. I also made a point of telling it not to feel constrained by what the skill covered — if it spotted something else, I wanted to know about it. The rest of this article walks through the vulnerabilities flagged and the mitigations put in place as a result. Uploaded HTML is directly executable on the app origin This was the critical issue that needed immediate attention. Issue: /api/pages/:id/content returns raw uploaded HTML as text/html from the primary app origin. The normal UI later injects CSP and loads it in a sandboxed blob iframe, but an attacker can share the direct API URL and bypass that isolation. Risk: Stored same-origin XSS. Even though the app has little user state today, this enables phishing, origin abuse, future privilege escalation, and admin-targeted attacks. Proposed fix: Add HTTP-level protection to content responses: at minimum Content-Security-Policy with sandbox allow-scripts plus the uploaded-page CSP, and X-Content-Type-Options: nosniff. Alternatively, return content as an attachment or move untrusted content to a separate origin. The first step to address this was to ensure the page routes include the following headers: Content-Security-Policy = "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'self'; object-src 'n...