Embedding external content inside Salesforce sounds simple until you hit Lightning Locker, CSP Trusted Sites, X-Frame-Options, and the AppExchange security review. This guide explains what iFrames in Salesforce actually are in 2026, where you can use them (Visualforce, LWC, Experience Cloud), why Salesforce restricts them, the better alternatives (Canvas Apps, native LWC), and what reviewers look for when you submit an iFrame-based managed package to AppExchange.

Pro Tip

TL;DR: An iFrame in Salesforce is an HTML <iframe> element that embeds external web content (a third-party app, dashboard, document, or URL) inside a Salesforce page. iFrames work in Visualforce pages directly, in Lightning Web Components with Lightning Locker restrictions, and in Experience Cloud sites via the Embedded Content component. Salesforce sets X-Frame-Options to SAMEORIGIN by default (anti-clickjacking), and external iframe targets must be added to CSP Trusted Sites. AppExchange security review evaluates iframe usage for clickjacking risk, session ID leakage, and missing CSP entries. Modern alternatives (Canvas Apps, native LWC with Apex callouts) are preferred over raw iframes for new builds.

An iFrame (inline frame) in Salesforce is an HTML <iframe> element that embeds external web content inside a Salesforce page. The embedded content can be a third-party SaaS app, a hosted dashboard, a PDF document, a video player, or any URL the browser can render. The iframe creates a sandboxed browsing context inside the parent Salesforce page.

Salesforce supports iframes in several rendering contexts but enforces strict security restrictions on them, especially in Lightning Experience. The platform's default behavior protects users from clickjacking and prevents unauthorized data exfiltration through embedded content.

Four primary locations support iframes, each with different restrictions.

ISVs distributing managed packages typically use option 1 (Visualforce) or option 2 (LWC). Visualforce iframes are easier but feel dated to users. LWC iframes are modern but require CSP configuration before installation works.

Two security threats drive the restrictions: clickjacking and session theft.

In a clickjacking attack, a malicious page loads a Salesforce page inside an invisible iframe and overlays UI to trick the user into clicking buttons they can't see. The user thinks they're clicking a normal link; they're actually approving a permission, deleting a record, or transferring data. Salesforce sets X-Frame-Options: SAMEORIGIN on all org pages to prevent third-party domains from framing Salesforce.

A poorly written iframe target page can read the parent page's URL parameters (including session IDs or auth tokens) via postMessage or referrer headers. Lightning Locker blocks cross-frame DOM access by default. CSP Trusted Sites lets admins whitelist only the specific external domains your managed package needs to embed.

Pro Tip

Citation capsule: Per the Salesforce Lightning Web Security documentation, LWS enforces sandboxing of each component's JavaScript execution context and limits cross-component DOM access, building on the prior Lightning Locker model.

By default, no. Salesforce sets X-Frame-Options to SAMEORIGIN, which blocks Salesforce pages from being embedded in iframes on third-party domains. This is anti-clickjacking protection at the platform level. If you try to embed an org URL into a non-Salesforce iframe, the browser refuses to render it.

To embed one Salesforce experience inside another, three options work:

• Visualforce <apex:include> to include another Visualforce page server-side.

• Lightning Web Component composition: import a child LWC and place it in your template.

• Lightning Out: embed Lightning Web Components into external pages with proper session token configuration.

Every external domain your iframe loads must be added to CSP Trusted Sites. Setup > Security > CSP Trusted Sites > New Trusted Site.

Pro Tip

Common pitfall: If your managed package iframe target loads sub-resources (analytics scripts, images on a CDN, fonts from a different domain), every subdomain also needs to be in CSP Trusted Sites. Use browser DevTools' Network tab during testing to catch every external domain.

AppExchange security review evaluates iframe usage carefully because iframes are a common vector for the failure causes that block ISVs. Reviewers check for:

Many AppExchange failures involve iframes that worked locally but fail review because the ISV didn't pre-configure CSP Trusted Sites or didn't document iframe usage in the Solution Architecture Document. See our 2026 security review guide for the full failure-cause breakdown.

Five modern alternatives avoid the iframe pain entirely.

Modern AppExchange ISVs default to Lightning Web Components with Apex callouts for fetching external data. iframes only make sense when you must embed a full third-party UI you don't own (like a hosted dashboard).

Canvas Apps are Salesforce's official framework for embedding a third-party application inside Salesforce with proper authentication and security. Canvas uses a signed-request pattern: Salesforce passes a signed JWT containing the user's identity and org context to your external app, which validates it server-side. Compare that to a raw iframe where you'd have to invent your own auth flow.

For ISVs distributing managed packages, Canvas Apps are the recommended pattern when you need to embed your own external SaaS UI inside Salesforce. Raw iframes are acceptable for read-only content from approved third-party vendors with proper CSP entries.

Some legacy managed packages use iframes for embedded dashboards or third-party UI. Modern AppExchange best practice is to avoid raw iframes in favor of native Lightning Web Components, Canvas Apps, or server-side Apex callouts.

AI-generated managed packages from platforms like Appnigma default to native LWC patterns with Apex callouts via Named Credentials. This avoids the iframe complexity entirely and ships AppExchange-ready code that clears the security review on the first pass. ISVs save weeks of CSP configuration and reviewer back-and-forth.

Pro Tip

Building a Salesforce-native integration? Skip the iframe headaches. Appnigma generates 2GP managed packages with native LWC and Apex callouts pre-configured. Book a demo.

An iFrame in Salesforce is an HTML <iframe> element that embeds external web content (a third-party app, dashboard, document, or URL) inside a Salesforce page. iFrames are commonly used in Visualforce pages, Lightning Web Components, Experience Cloud sites, and Lightning App tabs to display content that lives outside the Salesforce org.

Four primary locations: Visualforce pages (most flexible, direct HTML iframe tag), Lightning Web Components using lightning-iframe or a wrapped HTML iframe (with Lightning Locker / LWS restrictions), Experience Cloud pages via the Embedded Content component, and Lightning App tabs using Visualforce-wrapped iframes.

Lightning Locker and Lightning Web Security enforce strict CSP rules to prevent clickjacking, XSS, and unauthorized data access. The framework limits which domains can be loaded via iframe and blocks postMessage communication unless explicitly allowed. ISVs must add each iframe target domain to CSP Trusted Sites.

By default, no. Salesforce sets X-Frame-Options to SAMEORIGIN, which blocks Salesforce pages from being embedded in iframes on third-party domains. This is anti-clickjacking protection. To embed one Salesforce experience inside another, use Visualforce apex:include, Lightning Web Components composition, or Lightning Out instead of iframes.

Reviewers evaluate iframe usage for clickjacking risk, session ID leakage, and missing CSP entries. Every external iframe target must be declared in CSP Trusted Sites, justified in the Solution Architecture Document, and protected with X-Frame-Options or CSP frame-ancestors. iframes loading over HTTP, with missing CSP entries, or passing session IDs are common rejection causes.

Five alternatives: Native Lightning Web Components fetching data via Apex callouts, Salesforce Connect for external data virtualization, Canvas Apps for embedded third-party apps with proper signed-request auth, Platform Events for real-time data push, and Embedded Service Components for support widgets and chat. Modern AppExchange ISVs default to native LWC patterns.

Canvas Apps are Salesforce's official framework for embedding a third-party application with built-in signed-request JWT authentication, while raw iframes require you to invent your own auth flow. Canvas Apps are Salesforce-blessed and clear security review more easily. iframes are acceptable for read-only third-party content with proper CSP entries; Canvas Apps are recommended when you need to embed a full external SaaS UI.

Some legacy managed packages use iframes for embedded dashboards or third-party UI. Modern AppExchange best practice is to avoid iframes where possible and use Canvas Apps or native Lightning Web Components instead. AI-generated managed packages from platforms like Appnigma default to native LWC patterns and skip the iframe complexity.

• The 2026 managed packages guide. 1GP vs 2GP, namespaces, the upgrade lifecycle.

• The 2026 security review guide. Top 10 failure causes including iframe-related rejections.

• How to list on AppExchange. The full lifecycle.

• Salesforce integration tools and partners 2026. Native LWC vs iPaaS.

• Salesforce Lightning Web Security documentation

• CSP Trusted Sites configuration

• Canvas Apps Developer Guide

• Salesforce ISVforce Guide v66.0 Spring '26 PDF