Oh I hadn't thought of using CSP for that. CSP alone used to not be enough but combined with the iframe's sandbox attribute (or the relatively newer sandbox CSP

Oh I hadn't thought of using CSP for that. CSP alone used to not be enough but combined with the iframe's sandbox attribute (or the relatively newer sandbox CSP directives, which both block navigation and form submissions by default) then I think it's enough to block external network requests. This combo seems like a good solution for many use-cases. However there are certain things that it still doesn't protect against: CPU and memory exhaustion. Someone's script can hog those resources and possibly cause the browser to crash the tab. If you only execute one user's code at a time when a user of the site specifically browses to it / activates it, then it might be acceptable because a user can learn to not re-activate code that just crashed their tab and won't be missing out on anything else, but if you had a setup where it didn't take user action to run other users' code (like you have a homepage that automatically shows a running preview of other people's code, or you have a multiplayer programming game where each player submits code and everyone in the game sees it run together and interact with other players' code) then it could be purposefully griefed by players submitting code that exhausts resources. If you need to protect against local denial of service attacks like this, or if you needed strict determinism for some reason, then I think a WASM-based solution is still the way to go.