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.
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.
What are iFrames in Salesforce?
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.
Where can you use iFrames in Salesforce?
Four primary locations support iframes, each with different restrictions.
| Location | Method | Restrictions |
|---|---|---|
| Visualforce page | Direct <iframe> HTML tag in markup | Most flexible. Pages run in their own visualforce.com domain, separate from the org's salesforce.com domain. |
| Lightning Web Component (LWC) | lightning-iframe or wrapped HTML iframe | Lightning Locker / Lightning Web Security enforces CSP. Target domain must be in CSP Trusted Sites. |
| Experience Cloud (Communities) | Embedded Content component or HTML editor | CSP-restricted. Community admins configure trusted sites separately. |
| Lightning App tab | Visualforce-wrapped iframe used as tab content | Inherits Visualforce iframe behavior but renders inside Lightning shell. |
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.
Why does Salesforce restrict iFrames so heavily?
Two security threats drive the restrictions: clickjacking and session theft.
Clickjacking
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.
Session theft and data exfiltration
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.
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.
Can iFrames load Salesforce inside another website?
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.
How do you configure CSP Trusted Sites for iFrames?
Every external domain your iframe loads must be added to CSP Trusted Sites. Setup > Security > CSP Trusted Sites > New Trusted Site.
| Field | Value | Notes |
|---|---|---|
| Trusted Site Name | MyAppDomain | Internal label |
| Trusted Site URL | https://app.example.com | Must be HTTPS. Wildcards not allowed at protocol level. |
| Context | All / Lightning Experience / Communities | Match where the iframe renders |
| CSP Directives | frame-src, img-src, media-src, style-src, font-src, connect-src | Check 'frame-src' for iframe targets |
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.
How do iFrames affect the AppExchange security review?
AppExchange security review evaluates iframe usage carefully because iframes are a common vector for the failure causes that block ISVs. Reviewers check for:
| Check | What reviewers look for |
|---|---|
| CSP Trusted Sites declared | Every external iframe target must be in your package's post-install setup as a Trusted Site |
| HTTPS-only targets | iframes loading over HTTP fail review. Force HTTPS on every src. |
| No session ID leakage | iframes must not pass Salesforce session IDs to external pages via URL params or postMessage |
| X-Frame-Options compliance | Your iframe targets should themselves set X-Frame-Options to control where they can be embedded |
| Solution Architecture Document | Documents every external endpoint, including iframe targets, with justification |
| Clickjacking prevention | Demonstrates UI cannot be tricked into approving destructive actions |
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.
What are the alternatives to iFrames in Salesforce?
Five modern alternatives avoid the iframe pain entirely.
| Alternative | When to use | Why it's better than iframe |
|---|---|---|
| Native Lightning Web Component | Most cases | No CSP config required, full Lightning Experience styling, accessible by default |
| Apex callout to external API + render data in LWC | Embedding data, not UI | Server-side fetch via Named Credentials, no client-side cross-origin issues |
| Salesforce Connect (external objects) | Read-only external data displayed as Salesforce records | Native query support, no iframe needed at all |
| Canvas Apps | Embedding a full third-party app (legacy but ISV-friendly) | Salesforce-supported signed-request authentication, better than raw iframes |
| Embedded Service / Chat | Support widgets, chatbots | Purpose-built component with managed iframe under the hood |
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).
What's the difference between iFrames and Canvas Apps?
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.
| Dimension | Raw iFrame | Canvas App |
|---|---|---|
| Authentication | DIY (URL params, postMessage, custom) | Built-in signed-request JWT with user identity |
| Security review | Stricter scrutiny | Salesforce-blessed pattern, faster approval |
| Setup complexity | Add target to CSP Trusted Sites | Configure Connected App + Canvas App definition |
| User experience | External page in a frame | Looks more native, can use Lightning components |
| Best for | Quick embed of read-only content | Full third-party app integration |
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.
Do managed packages on AppExchange use iFrames?
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.
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.
Frequently asked questions
What are iFrames in Salesforce?
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.
Where can you use iFrames in Salesforce?
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.
Why does Salesforce restrict iFrames in Lightning?
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.
Can iFrames load Salesforce pages inside other websites?
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.
How do iFrames affect the AppExchange security review?
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.
What are alternatives to iFrames in Salesforce?
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.
What's the difference between iFrames and Canvas Apps?
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.
Do managed packages on AppExchange use iFrames?
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.
Where to go next
- 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.
