RFC-116: New link egress type for Forge apps

General Request for Comments (RFC)
,
21

Hi @VickyHu,

We are currently working on a Forge app for Confluence Cloud where we need to render YouTube video thumbnails and playable embedded videos inside the app.
These YouTube links are already part of the main Confluence page — our app simply reads those links and renders them properly, allowing users to play the videos in embedded form.

To achieve this, we currently use the following external URLs:

# external:
#   frames:
#     - 'www.youtube.com'
#   images:
#     - 'img.youtube.com'

and generate URLs like:

const getYoutubeThumbnail = (id) => `https://img.youtube.com/vi/${id}/hqdefault.jpg`;
const getYoutubeEmbedUrl = (id) => `https://www.youtube.com/embed/${id}?autoplay=1`;

The iframe is used purely for video playback within the app — no user data, configuration, or analytics is sent to YouTube from our side.
However, due to the current egress and RoA rules, our app loses the “Runs on Atlassian (RoA)” badge simply because of this static embed.

From our perspective, this should not be classified as data egress, since it’s only a media playback action initiated by the user (similar to how a static link opens an external site).

We would really appreciate if this RFC (or a related mechanism) could consider:

  • Allowing trusted media domains like youtube.com and img.youtube.com to be declared under the proposed links or frames permission type.

  • Or alternatively, enabling safe static embeds (like YouTube iframes) to be whitelisted without affecting RoA status.

Since wildcards (*) aren’t allowed, it’s not feasible to list all possible YouTube video URLs in the manifest. We believe supporting domain-level allowlisting for well-known public content providers (e.g., YouTube, Vimeo) would strike a good balance between maintaining security and enabling richer user experiences inside Forge apps.

Thanks,
Mohan Kanawade
Forge App Developer

1 Like