Security and limitations
Remote Content is a thin wrapper around a browser frame. Understanding what that means is most of what there is to know about its security.
What the app does and does not do
| Backend | None. There is no server of ours in the request path. |
| Confluence API permissions | None requested. The app cannot read your pages, spaces, users, or attachments. |
| App storage | None. Configuration lives in your Confluence page, saved by Confluence. |
| Network calls of its own | None. The only request it causes is your browser loading the address you configured. |
| Analytics or telemetry | None. |
The app declares permission to frame any address, because the address is whatever a page author types. That declaration lets your browser load the target; it grants the app no access to the target’s contents.
The embedded page is a separate document
An embedded site is loaded by your browser, in a frame, from that site’s own servers. It is subject to the browser’s same-origin policy in both directions:
- The Confluence page cannot read the embedded document, its cookies, or anything a user types into it.
- The embedded document cannot read the Confluence page around it.
- The app itself cannot read either. It knows the address and nothing else.
This also means the embed carries your browser’s existing session with the target. If you are signed in to a dashboard in another tab, the embed will usually show it signed in — for you. A colleague viewing the same Confluence page sees whatever their own session grants them, which may be a sign-in screen or an error. An embed is not a way to share access to a system.
Addresses the app refuses
Only http: and https: addresses are embedded. javascript: and data: are refused specifically because they are ways to execute script in the frame; ftp: and file: are refused because they cannot be framed usefully. An address without a scheme is treated as https.
When a site refuses to be framed
Most sites that handle accounts or money forbid framing, using the X-Frame-Options header or a frame-ancestors content security policy. This is a defence against clickjacking and it works as intended: no Confluence app can override it, and one that claimed to would be describing a browser vulnerability rather than a feature.
The macro detects the refusal and replaces the blank frame with an explanation and an Open in new tab button.
That detection is a heuristic. It reads whether the frame ever left its blank starting document, and it gives up after five seconds. A slow site may occasionally be reported as refused when it would have loaded given longer, and a site may occasionally load quietly after the message appears. This is tolerable because the escape hatch does not depend on it: the Open in new tab button is present on every embed, in every state, so the target is always one click away.
Practical guidance
- Prefer targets whose owners intend them to be embedded. Many services publish an embed-specific URL for exactly this purpose.
- Do not put credentials, tokens, or private identifiers in the address. A macro URL is Confluence page content: it is stored in the page, visible to everyone who can view or export it, and it travels in the browser’s request to the target.
- Remember that page-edit permission is the control here. Whoever can edit a page can point a macro at any address, and readers of the page will load it. Treat that the way you treat any other content permission.
- Do not rely on Hide scrollbars. It is best-effort and, against a cross-origin target, inert. See Macro settings.
- An embed does not make external content part of your Confluence site. It is not indexed, not searchable, not exported with the page, and not retained if the target changes or disappears.