Adjust `sandbox` attribute for Sutori embeds via oEmbed discovery

[yoran]

Description

We provide an oEmbed endpoint. Its discovery in WordPress works but the resulting embed is not working due to a security restriction on the <iframe> embed. More specifically, setting sandbox="allow-scripts allow-same-origin" instead of sandbox="allow-scripts" (the default) results in a functioning embed. You can view a ​non-working embed here and ​a working embed.

We've had multiple users requesting to embed Sutori into their WordPress blog so therefore we would like to find a solution.

We see two options:

1. Adding an exception to the embed code sanitizer used by oEmbed Discovery to add the allow-same-origin permission on the sandbox attribute.
2. Whitelist Sutori as a provider.

We think the first option would be less intrusive for the WordPress codebase and sufficient for our use cases. Our full embed code adds <script> tags in order to automatically adjust the height of the iframe according to the content. These tags are stripped by the WordPress sanitizer, effectively fixing the height of the iframe and adding a scrollbar.

Before we submit a patch, we would like to hear the opinion of WordPress contributors whether you think the first option is also the best way to go from WordPress' point of view.

About Sutori

​Sutori is a collaborative visual story builder that helps students garner 21st century skills of collaboration, creativity, critical thinking and communication.

Is the service is popular enough for core developers to have heard of it before? Is it “mainstream?”

At the time of writing, Sutori has over 800,000 users around the world. About 80% of those are K-12 students and teachers.

If similar services are already supported, how does this service compare in terms of size, features, and backing?

There are other presentation tools supported in WordPress (SlideShare, Speaker Deck) but none of them are education-focused. Sutori would be the first one.

Does this service have a large following on Twitter, Facebook, or other social media? Is its Twitter account verified?

The Twitter account (​https://twitter.com/SutoriApp) has about 3300 followers.

Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)

The endpoint is documented on ​https://oembed.com/.

Does the oEmbed endpoint work with WordPress’ oEmbed auto-discovery? If not, could it be made to work with additional HTML tags or attributes being whitelisted?

See explanation above. It is discovered but the sandbox attribute on the iframe is too restrictive.

Does the service make an effort to build relationships with developers, such as through robust APIs?

Sutori does not have an open API. It is implemented as a single-page application so the frontend is the sole consumer of the API.

How old is the service?

We launched in 2014.

Does it have a well-established Wikipedia article? (Seriously.)

Sutori does not have a Wikipedia article.

Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?

As far as we know, there is no WordPress plugin that leverages Sutori.

Is the provider frequently proposed?

This is the first time.

[swissspidy]

Hey there and welcome to WordPress Trac!

Our full embed code adds <script> tags in order to automatically adjust the height of the iframe according to the content.

WordPress already does that for you. So to me it sounds like the easiest thing to do for your platform is to support the WordPress embed script issuing postMessage calls to set the iframe height. As one of the developers behind this WordPress embed sandboxing, I'd be happy to help you with that.

Since your oEmbed endpoint is almost fully working with WP already, it doesn't really make sense to whitelist it.

Adding allow-same-origin would have quite an impact that would go way beyond allowing 1 smaller website to set the iframe's height. For example, it has consequences for usage of cookies, local storage, etc.

[yoran]

Thanks for your prompt reply.

Adding allow-same-origin would have quite an impact that would go way beyond allowing 1 smaller website to set the iframe's height. For example, it has consequences for usage of cookies, local storage, etc.

The main issue we're seeing is that some of the external Javascript libraries that Sutori loads can't deal with document.cookie throwing an exception, which happens when allow-same-origin is not added. This exception causses the embed to not show at all.

There are two ways we can go about it:

1. Fix this on our end so that Sutori loads fine without allow-same-origin.
2. Add an exception to the Wordpress embed sanitizer to add allow-same-origin when embedding a resource from the sutori.com domain.

Are there any services that have exceptions like 2, i.e. whitelist or extend certain attributes on the iframe? If so, I was hoping we could add Sutori as such an exception.

The non-automatically resizing of the iframe is not as critical and something that we can fix separately, using the inter-frame communication method you described.

[swissspidy]

Are there any services that have exceptions like 2, i.e. whitelist or extend certain attributes on the iframe? If so, I was hoping we could add Sutori as such an exception.

No, there aren't any such exceptions in core right now. Adding allow-same-origin for your site only would set quite a precedent. Adding it for every site just because of this is also dangerous without carefully verifying at the consequences.

Sort of related: #44281.

Suggesting wontfix.