Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.
(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)
And I serve the content in srcdoc= to ensure there's no URL a user can visit which would directly execute the content outside of that iframe sandbox.
It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.
I'm not convinced it's true - I've been thinking about this for months, and building experimental prototypes to help me get to the combination that I think makes sense.
Can you describe an exploit that the combination I'm using of iframe sandbox= srcdoc= with an injected meta CSP tag doesn't handle?
Would moving the untrusted content to be served from a separate domain entirely close the hole?
(In case it's not clear the iframe sandbox= is the bit that's doing most of the work here - the CSP stuff is there mainly to protect against malicious apps that deliberately exfiltrate stolen private data.)
