Skip to main content
Sometimes you need to go beyond Curator’s standard embedding capabilities and embed content from your unique or legacy systems into Curator. That’s where Curator’s Manual Embeds feature comes to the rescue! We’ll walk you through the steps to seamlessly embed any other website, using iFrames, into your Curator pages! Important Considerations:
  • While you’re adding Manual Embeds, keep in mind that the embed code should come from trusted sources. This will help you avoid any security risks or funky user experiences.
  • Some systems might require some extra configuration or customization to display perfectly within an iFrame. Check out the documentation or support resources for the specific system you’re embedding to ensure compatibility and the best possible display.
  • Don’t forget to pay attention to the dimensions and aspect ratio of the iFrame content. We want it to fit smoothly within your Curator page. Adjust those dimensions if needed, so you avoid any cropping or weird distortions.

​
Adding a Manual Embed to a Page

  1. Login to the backend of your Curator instance (e.g. https://www.curatorexample.com/backend ).
  2. Navigate to the Content > Pages section from the left-hand menu.
  3. Find the page you’d like to add your Manual Embed to, or click the ”+ New Page” button.
  4. On the page builder editor, click the section you’d like to add your embed to, or click the ”+” icon on the page builder page to add a new section.
  5. Click the “Additional Elements” tab from the “Add Element” popup and select the Embed content type.
  6. Choose the dropdown option that best fits your need from the options below
    • iFrame: For use when pasting in a simple URL (e.g. https://mycuratorexample.com/embed)
    • Embed Code (HTML): For use when copying embed code from another website - this will be in HTML and can be identified by searching the copied code for </iframe> - if this string is found in your code it means you are using an iFrame to embed.
  7. Once you’ve pasted the correct information in, click “Add”

​
URL Parameter Substitution

When you use the iFrame option (a plain URL), Curator can substitute the following placeholders in the URL with the signed-in user’s details. Substitution happens server-side, only when a user is logged in, and only for the iFrame option — placeholders are not processed in the Embed Code (HTML) option. Placeholder matching is case-insensitive. For example, https://myapp.example.com/report?user=[USERNAME] renders as https://myapp.example.com/report?user=jane.smith@company.com for the signed-in user. This lets the embedded application receive the current user’s identity in the URL without Curator forwarding any session tokens.

​
Authentication Limitations

Curator’s iFrame embed renders the target URL inside a browser frame — it does not broker authentication between Curator and the embedded application. Specifically, Curator does not:
  • Forward Curator session cookies or authentication tokens to the embedded application.
  • Intercept HTTP 3xx authentication redirects that happen inside the iframe.
  • Detect when an iframe is displaying a login page instead of the intended content.
If the embedded application has its own authentication requirement (for example, an OIDC/OAuth login flow), users who are not already authenticated to that application will see the application’s own login UI inside the iframe. Whether the iframe renders at all depends on the target application’s own framing policy:
  • X-Frame-Options: DENY — The application refuses all iframe embedding; the frame appears blank.
  • X-Frame-Options: SAMEORIGIN — The application only allows framing from its own origin, so it will not load inside Curator (a different origin). The frame appears blank.
  • A Content-Security-Policy header on the target — The browser may block the frame depending on the policy.
When you add or edit an iFrame URL in the page builder, Curator checks the target URL’s response headers and warns you in the editor if the target appears to block framing (an X-Frame-Options of DENY, a SAMEORIGIN value that doesn’t match your Curator host, or the presence of a Content-Security-Policy header). This check is a build-time convenience in the editor; it does not run when visitors view the published page, so always confirm the embed renders correctly on the live page. Recommended approach for applications with their own authentication:
  1. Work with the target application’s team to explicitly allow framing from your Curator domain — for example, by setting Content-Security-Policy: frame-ancestors 'self' https://analytics.yourcompany.com on the target application.
  2. Ensure the target application’s session cookies use SameSite=None; Secure so browsers transmit them in cross-site iframe requests.
  3. If the target application supports token-based deep links, use the [USERNAME] placeholder in the iFrame URL to pass the user’s identity to a token-exchange endpoint on the target side, avoiding an inline login form.
There is no Curator-side configuration to open an authentication flow in a new tab and return to the embed once authentication is complete.

​
Content Security Policy and Framing Headers

Curator sets the following security-related response headers on its own pages. These govern how Curator pages behave — they do not restrict which origins Curator’s iframes may load from:
  • X-Frame-Options: sameorigin — Controls whether Curator itself can be framed by another site. On rendered pages this header is omitted when the portal Allow iframe embedding setting is enabled, so that Curator can be embedded elsewhere.
  • Content-Security-Policy: upgrade-insecure-requests — Applied when the portal Force SSL setting is enabled. It upgrades mixed HTTP/HTTPS sub-resource requests; it does not restrict iframe sources.
  • X-Content-Type-Options: nosniff — Prevents MIME-type sniffing; it does not affect iframe loading.
Cross-origin embedding restrictions are enforced by the target application’s headers, not by Curator’s.