More explicitly recommend iframe for PDFs - #45614
Conversation
github-actions
Bot
added
Content:HTML
| If absolutely required, you can add permissions back one by one (inside the `sandbox=""` attribute value) — see the [`sandbox`](/en-US/docs/Web/HTML/Reference/Elements/iframe#sandbox) reference entry for all the available options. One important note is that you should _never_ add both `allow-scripts` and `allow-same-origin` to your `sandbox` attribute — in that case, the embedded content could bypass the [Same-origin policy](/en-US/docs/Glossary/Same-origin_policy) that stops sites from executing scripts, and use JavaScript to turn off sandboxing altogether. | ||
| If absolutely required, you can add permissions back one by one (inside the `sandbox=""` attribute value) — see the [`sandbox`](/en-US/docs/Web/HTML/Reference/Elements/iframe#sandbox) reference entry for all the available options. One important note is that you should _never_ add both `allow-scripts` and `allow-same-origin` to your `sandbox` attribute when the embedded content has the same origin as the embedding page — in that case, the embedded content could use JavaScript to remove the attribute and reload itself to turn off sandboxing altogether. | ||
|
|
||
| This advice applies to embedded HTML and SVG documents, where the embedded script might access the outside. For PDF documents, the browser's built-in PDF viewer already sandboxes any executable content. In fact, adding `sandbox` may prevent the PDF viewer from working. |
There was a problem hiding this comment.
I think this is a bit elliptical: is "this advice" the whole section "use the sandbox attribute" or just the bit we were just talking about? Is the guidance we want to give: that "if you are using an iframe to display a PDF, don't use sandbox? If so we should say that clearly.
Is it even worth having a separate section on embedding PDFs using iframes, since ISTM that a lot of this guidance doesn't apply there.
There was a problem hiding this comment.
I meant you shouldn't use sandbox.
Are you suggesting a single "Embedding PDFs" section on this page, or such a subsection for each of the two H2 sections (<iframe> and <object>)? TBH there's really not that much to talk about, other than that the browser sandboxes the PDF by itself.
There was a problem hiding this comment.
OK so I think I'm being a bit of a perfectionist maybe but. A lot of this page is implicitly and sometimes explicitly only about embedding documents.
Especially, the core of this page, "iframes in detail" as far as I can see is all about embedding documents. That section starts off with "<iframe> elements are designed to allow you to embed other web documents into the current document" and doesn't mention PDFs at all until this bit at the end about sandboxing, and includes lots of other guidance that's not relevant to PDFs, like clickjacking. But none of this is really very clearly signposted.
So I thought it might be clearer if this doc had a separate standalone H2 on "Embedding PDFs", that covers just this niche topic, and let the rest of the page be about embedding documents.
But maybe it's not worth it. TBH this document has lots of other problems, but they're not caused by this PR.
There was a problem hiding this comment.
explicitly only about embedding documents
What does "D" in "PDF" stand for again? 😆
Added an "Embedding PDFs" section.
Co-authored-by: wbamberg <will@bootbonnet.ca>
3 participants
Fix #44512. I did some research and came to the conclusion that there's no real reason to use
<object>or<embed>at all for any purpose.