Playground

Running a TypeScript playground is where nice, clean CSP ideas go to get punched in the face. You want a browser app that accepts arbitrary code, transpiles it, maybe runs it in a preview, stores snippets, loads analytics, and still keeps a tight Content Security Policy. That combination gets messy fast. I’ve built this kind of thing before, and the first version usually cheats: unsafe-inline, unsafe-eval, and a quiet promise to “fix it later.” ...

If you’re building a Rust Playground-style app, your threat model is ugly in all the fun ways. You’re taking user input, compiling or executing code, rendering output, maybe embedding an editor, maybe shipping WebAssembly, and probably sprinkling in some analytics or third-party UI bits because product people always want one more script. That’s exactly the kind of app where Content Security Policy earns its keep. A Rust Playground is not just “another website.” It’s a code execution surface with a browser front end. Even if your actual Rust execution happens in a locked-down backend container, your frontend is still exposed to XSS, supply-chain script injection, data exfiltration, and clickjacking. CSP helps reduce that blast radius. ...

If you’re building a Go playground-style app, CSP gets weird fast. A regular Go web app might serve a few static JS files and call it a day. A playground usually does more: runs user code or sends it to a backend sandbox opens WebSocket connections for logs or interactive output injects bootstrapping data into the page embeds editors like Monaco or CodeMirror uses inline scripts because templating makes it convenient That combination is exactly where sloppy CSP setups happen. ...