Use iframe with sandbox attribute for PDF preview instead of embed

The problem

PDF previews, which, for some reason, use embed since the feature has been added. However, we could also use the (more modern and IMHO more secure) iframe. This would also allow using the sandbox attribute to further restrict the PDF previews from doing something bad.

Tested it "a bit" trying to find actual security issues here, but it all depends on the PDF viewer, that would need an XSS vulnerability first (which is not unrealistic), so IMHO, this is more a defense-in-depth - though very useful, as such "attack chains" with an PDF viewer XSS are plausible.

Also the CSP issue that you need to loosen your CSP can be re-evaluated then (maybe object-src is not necessary anymore?). It could be iframe's in their own context can work, but also maybe you still need some adjustments to frame-src.

The solution

Manually tried that changing embed to iframe seems to work. Also, I tested it with this sandbox and that seems to work fine: sandbox="allow-scripts allow-downloads allow-top-navigation-by-user-activation"

• scripts are needed for the JS Firefox PDF renderer (pdf.js) to render
• downloads are obvious
• allow-top-navigation-by-user-activation is useful to restrict links in the PDF file, but also to allow them. We cannot force them to open in a new tab (as in HTML), but disallowing them alltogether IMHO would also be a bad UX. Note at least pdf.js even shows a "yellow overlay" even on a "white page" with a full link - aka this kinda prevents phishing, does not it?

Notably this e.g. restricts the "same-origin" aka is a defense-in-depth against XSS attacks.

Alternatives

Additional context

See https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/General_embedding_technologies for background information on embedding.

Funnily https://github.com/PrivateBin/PrivateBin/issues/14 always talked about an iframe, but technically never used it.