Comment by est
4 hours ago
I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?
4 hours ago
I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?
If you host iframe apps at a fixed URL like:
You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly)
If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns.
Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected.
I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".
CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.
Right, which is why I'm combining it with <iframe sandbox=""> - which really is designed to be used as a sandbox (if you can figure out the right way to implement it.)
[dead]