HTML iframe: Embed External Content Without Wrecking Your Site
- An iframe is a separate browsing context, not a component — it has its own DOM, JavaScript runtime, cookies, and history stack. Treating it like a div with a src attribute is how production security holes get opened.
- Always add the sandbox attribute to third-party iframes and explicitly whitelist only the capabilities you've consciously decided to grant. The six-hour phishing incident I described in the intro was preventable with two attributes and thirty seconds of thought.
- postMessage is the only safe cross-origin communication channel — but it's only safe when both sides verify event.origin before touching event.data. An origin check is one line of code. Skipping it turns your postMessage listener into an open door for any page on the internet.
I watched a fintech startup's customer dashboard silently serve a phishing page for six hours because a junior dev dropped an unsandboxed iframe pointing to a third-party widget — and that widget's CDN got compromised overnight. Six hours. The iframe loaded fine, passed every smoke test, and nobody noticed until a user's bank credentials were gone. The iframe itself wasn't the villain. The missing two attributes were.
Iframes exist because the web has always needed a way to embed one document inside another without merging their code, styles, or execution contexts. Before iframes, teams resorted to framesets — a now-dead HTML construct that split the browser window into panes like a spreadsheet, sharing a single URL for all of them. SEO hated it, accessibility hated it, and back buttons behaved like a drunk intern. Iframes replaced that mess and gave us a clean, isolated container. Today they're everywhere: YouTube embeds, Google Maps, Stripe's payment form, OAuth popups, and countless dashboards are all iframes you interact with every day without realising it.
By the end of this you'll be able to drop an iframe onto any page with the right security attributes locked down, understand exactly why cross-origin restrictions exist and how to work with them instead of fighting them, communicate between a parent page and an embedded iframe using postMessage without opening security holes, and diagnose the three most common iframe failures that show up in production — blank frames, refused connections, and broken layouts — and fix them in under five minutes.
What an iframe Actually Is and How the Browser Handles It
Before writing a single line, you need to understand what the browser is doing when it hits an iframe tag — because it's not just 'rendering HTML inside HTML.' The browser treats an iframe as a completely separate browsing context. That means its own DOM, its own JavaScript runtime, its own cookies, its own history stack, and its own set of security policies. It's less like a component and more like opening a second browser tab and pinning it inside your page.
When your page loads and the parser hits an <iframe src="https://example.com">, the browser fires off a completely independent HTTP request for that URL. It negotiates its own headers, handles its own redirects, and builds a separate document tree. Your page's JavaScript has no access to that inner document if the src is on a different origin — that's the Same-Origin Policy at work, and it's not optional.
Why does this matter right now? Because every resource inside that iframe — every image, script, font, and API call — is a network request your user's browser makes. Embed three heavy third-party widgets with iframes and you've tripled your page's external dependency surface. I've seen a dashboard page go from a 1.2-second load to 6.8 seconds because four analytics iframe widgets each pulled 400KB of JavaScript independently. The host page was fast. The iframes murdered it.
<!-- io.thecodeforge — JavaScript tutorial --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Support Dashboard — TheCodeForge</title> <style> body { font-family: system-ui, sans-serif; margin: 0; padding: 24px; background: #f5f5f5; } .embed-container { /* Fixed-size wrapper so the iframe doesn't collapse to 0x0 or expand to fill the entire viewport unexpectedly */ width: 100%; max-width: 900px; /* The padding-bottom trick creates a responsive aspect ratio. 56.25% = 9/16 — standard widescreen ratio for video embeds */ padding-bottom: 56.25%; position: relative; height: 0; background: #000; /* Visible while the iframe loads */ } .embed-container iframe { /* Stretch to fill the responsive wrapper completely */ position: absolute; top: 0; left: 0; width: 100%; height: 100%; border: none; /* Default iframe border looks terrible — always remove it */ } </style> </head> <body> <h1>Product Walkthrough Video</h1> <div class="embed-container"> <!-- src — The URL of the document to embed. Always use HTTPS. HTTP src on an HTTPS page is blocked as mixed content by every modern browser. title — REQUIRED for accessibility. Screen readers announce this so visually-impaired users know what the frame contains. Skipping it is an automatic WCAG 2.1 Level A failure. loading="lazy" — Tells the browser not to fetch this iframe until it's close to the viewport. Crucial for pages with multiple embeds — don't skip this. allowfullscreen — Lets the embedded content request fullscreen mode. YouTube, Vimeo, and Loom all need this. --> <iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ" title="TheCodeForge: Product Walkthrough — Never Gonna Give You Up" loading="lazy" allowfullscreen ></iframe> </div> <p>Watch the full walkthrough above before starting the setup guide.</p> </body> </html>
The sandbox Attribute: Your First Line of Defence Against Malicious Embeds
Here's the thing nobody explains clearly: when you embed a third-party URL in an iframe without the sandbox attribute, that content can run JavaScript, submit forms, open popups, redirect your top-level page, and access browser APIs — all under the user's session. If that third-party CDN gets compromised, your users are compromised. The iframe is the attack surface.
The sandbox attribute locks the iframe into a maximum-restriction mode by default. With sandbox and nothing else, the embedded content can't run scripts, can't submit forms, can't access cookies, can't open new windows, and can't navigate the parent frame. It becomes a completely inert display container. Then you explicitly opt back into only the capabilities you actually need by adding tokens to the attribute value.
This is the principle of least privilege applied to HTML. Don't grant capabilities you haven't reasoned about. I've seen teams embed third-party chat widgets, analytics dashboards, and marketing tools without sandbox — any one of those vendors getting breached means your users' sessions are at risk. The Stripe payment iframe you see on checkout forms uses sandbox internally. Stripe's own security documentation mandates it for embedding their pre-built UI. If Stripe thinks it's necessary, you do too.
<!-- io.thecodeforge — JavaScript tutorial --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Customer Dashboard — Sandboxed Widgets</title> <style> .widget-frame { width: 100%; height: 320px; border: 1px solid #e0e0e0; border-radius: 8px; } </style> </head> <body> <h2>Live Chat Support</h2> <!-- SCENARIO: Embedding a third-party chat widget. We don't control their codebase. We need to be explicit about exactly what we're allowing — nothing more. --> <iframe src="https://support-widget.example.com/chat" class="widget-frame" title="Live support chat widget" loading="lazy" sandbox=" allow-scripts allow-same-origin allow-forms allow-popups-to-escape-sandbox " <!-- sandbox token breakdown: allow-scripts — Lets the embedded content run JavaScript. Without this, the chat widget is a dead image. WARNING: Never combine allow-scripts with allow-same-origin on content you HOST YOURSELF at the same origin — that combo lets the iframe script remove its own sandbox. Safe here because this is a DIFFERENT origin. allow-same-origin — Lets the iframe be treated as coming from its actual origin rather than a synthetic opaque origin. Needed so the widget can read its own cookies and localStorage (e.g. to remember the user's chat session). allow-forms — Lets the user actually submit a message in the chat form. Without this, form submissions are silently swallowed. allow-popups-to-escape-sandbox — Lets any popup the widget opens (e.g. 'Open in full window') exist as a normal unsandboxed tab. Without this, popups inherit the sandbox — they open but can't do anything useful. INTENTIONALLY OMITTED: allow-top-navigation — Would let the widget redirect your entire page. Never grant this to untrusted third parties. allow-modals — Would let the widget call alert() and confirm(). Annoying and a potential phishing vector. --> ></iframe> <h2>Static Terms of Service Document</h2> <!-- SCENARIO: Embedding a plain HTML document — no interaction needed. Maximum restriction. No tokens granted at all. The document renders but can't do anything. --> <iframe src="https://legal.example.com/terms-v3.html" class="widget-frame" title="Terms of Service document version 3" loading="lazy" sandbox ></iframe> </body> </html>
Terms of Service iframe renders the HTML document as static content only — no JavaScript executes, no forms work, no navigation possible. Both iframes show no console errors.
allow-scripts and allow-same-origin, the iframe's JavaScript can call frameElement.removeAttribute('sandbox') and completely remove its own restrictions at runtime. The sandbox becomes theatre. Only combine those two tokens when the embedded content is on a different origin than the parent page.Cross-Origin Communication: How Parent and iframe Actually Talk to Each Other
The Same-Origin Policy means your parent page's JavaScript can't reach into a cross-origin iframe's DOM and touch anything. You can't read its form values, you can't call its functions, and it can't call yours — directly. This isn't a bug; it's the entire reason you can safely embed a bank's payment form inside your checkout page without your JavaScript being able to steal card numbers.
But you still often need the two documents to coordinate. The embedded payment form needs to tell your parent page 'payment succeeded' or 'validation failed.' A Google Maps iframe needs to tell your page what address the user selected. The mechanism for this is window.postMessage — a deliberately narrow, controllable channel that lets two documents exchange messages without breaching the isolation boundary.
postMessage works like passing a note under a door. You push a serialised message from one window, it arrives as a message event on the other side, and — critically — the receiver must verify the sender's origin before trusting the content. Skipping that origin check is one of the most common XSS vectors in iframe-heavy applications. I've found it in three separate production codebases during security reviews. The fix is one line, but nobody thinks to add it.
// io.thecodeforge — JavaScript tutorial // ───────────────────────────────────────────────────────────────── // SCENARIO: E-commerce checkout page (parent) embeds a payment form // iframe hosted on a separate PCI-compliant subdomain. // The iframe must signal payment results back to the parent // without the parent ever touching the card input fields. // ───────────────────────────────────────────────────────────────── // ── FILE 1: checkout.js (runs on the PARENT page) ───────────────── const PAYMENT_IFRAME_ORIGIN = 'https://payments.thecodeforge.io'; // Hardcode the exact expected origin — not a wildcard, not a regex. // This is the ONE thing that prevents a malicious page from // impersonating your payment iframe. const paymentFrame = document.getElementById('payment-iframe'); // ── Sending a message TO the iframe ────────────────────────────── function initiateCheckout(orderDetails) { // postMessage(message, targetOrigin) // The second argument restricts delivery — the message is ONLY // delivered if the iframe's current origin matches. // Never pass '*' as the target when sending sensitive data. paymentFrame.contentWindow.postMessage( { type: 'CHECKOUT_INIT', orderId: orderDetails.orderId, amountInCents: orderDetails.amountInCents, currency: orderDetails.currency }, PAYMENT_IFRAME_ORIGIN // Message is silently dropped if iframe origin doesn't match ); } // ── Receiving messages FROM the iframe ─────────────────────────── window.addEventListener('message', function handlePaymentResult(event) { // CRITICAL: Always verify origin FIRST, before touching event.data. // Without this check, ANY page can postMessage your window // and inject fake payment confirmations. if (event.origin !== PAYMENT_IFRAME_ORIGIN) { console.warn( `[Checkout] Rejected message from unexpected origin: ${event.origin}` ); return; // Drop it. Do not process. } // Verify the message has the shape we expect // before trusting any of its fields. const { type, payload } = event.data; if (!type || typeof type !== 'string') { console.warn('[Checkout] Malformed message received — missing type field'); return; } switch (type) { case 'PAYMENT_SUCCESS': // payload.transactionId comes from our trusted payment subdomain redirectToOrderConfirmation(payload.transactionId); break; case 'PAYMENT_FAILED': displayPaymentError(payload.userFacingMessage); break; case 'IFRAME_READY': // The iframe signals when it has fully loaded and is ready // to receive the CHECKOUT_INIT message. Sending before this // event means the message arrives before the listener is attached. initiateCheckout(getPendingOrderDetails()); break; default: // Unknown message types are silently ignored — don't throw here, // browsers and extensions also fire message events on your window. break; } }); // ── FILE 2: payment-form.js (runs INSIDE the iframe) ────────────── const PARENT_CHECKOUT_ORIGIN = 'https://shop.thecodeforge.io'; // Signal to the parent that this iframe is loaded and its // message listener is registered. Parent waits for this before // sending order details — avoids a race condition where // CHECKOUT_INIT fires before the iframe listener exists. window.parent.postMessage( { type: 'IFRAME_READY' }, PARENT_CHECKOUT_ORIGIN ); window.addEventListener('message', function handleCheckoutInit(event) { // Same origin check — this iframe must also verify the sender. // The parent page could itself be compromised; don't trust blindly. if (event.origin !== PARENT_CHECKOUT_ORIGIN) { return; } const { type, orderId, amountInCents, currency } = event.data; if (type !== 'CHECKOUT_INIT') return; // Populate the payment form with order details received from parent renderPaymentForm({ orderId, amountInCents, currency }); }); function handleFormSubmitSuccess(transactionId) { window.parent.postMessage( { type: 'PAYMENT_SUCCESS', payload: { transactionId } }, PARENT_CHECKOUT_ORIGIN ); } function handleFormSubmitFailure(errorMessage) { window.parent.postMessage( { type: 'PAYMENT_FAILED', payload: { userFacingMessage: errorMessage } }, PARENT_CHECKOUT_ORIGIN ); }
[Checkout] Rejected message from unexpected origin: https://evil-site.com
Normal flow (no suspicious origins):
— iframe fires IFRAME_READY → parent receives it, calls initiateCheckout()
— Parent sends CHECKOUT_INIT to iframe with order details
— User fills card form, submits
— iframe fires PAYMENT_SUCCESS with transactionId
— Parent receives it, calls redirectToOrderConfirmation('txn_abc123')
No card data ever touches the parent page's JavaScript context.
postMessage(sensitiveData, '*') sends your message to any origin currently loaded in that frame — including if the frame was navigated to a malicious page after you sent. I've found this pattern in two fintech dashboards sending authentication tokens to iframes with wildcard targets. The fix: always pass the exact target origin string as the second argument. One extra string literal, zero ambiguity.iframe Refuses to Load: The X-Frame-Options and CSP Reality Check
You drop an iframe pointing to a legitimate, public website and get a blank frame. No content, no error message on the page — just empty space. You open DevTools and see something like: Refused to display 'https://example.com' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'. This is the most common iframe confusion in the wild, and it's not a bug in your code.
Websites actively prevent themselves from being embedded. There are two mechanisms: the legacy X-Frame-Options response header (values: DENY or SAMEORIGIN) and the modern Content-Security-Policy: frame-ancestors directive. Both are set by the server of the page you're trying to embed — not by you. If they've set these headers, you cannot override them from the client side. No JavaScript trick, no attribute, nothing. The browser enforces it at the network level.
This is why you can't embed google.com, twitter.com, or most banking sites in an iframe. They've set X-Frame-Options: DENY or CSP: frame-ancestors 'none'. You can only embed content that explicitly permits embedding — either by omitting these headers or by setting frame-ancestors to include your origin. If you're building something you want others to embed, you control this from your server. If you're trying to embed someone else's site and they've blocked it, the answer is: you can't, and that's intentional.
// io.thecodeforge — JavaScript tutorial // ───────────────────────────────────────────────────────────────── // SCENARIO: Your engineering team built a micro-frontend dashboard. // A new service refuses to embed. Here's how to diagnose it // and how to configure your OWN service to embed correctly. // ───────────────────────────────────────────────────────────────── // ── DIAGNOSIS: detect when your iframe silently fails to load ───── const reportingFrame = document.getElementById('analytics-frame'); reportingFrame.addEventListener('load', function verifyIframeLoaded() { // The 'load' event fires even when the browser blocks the content // and shows an error page. We can't inspect contentDocument // cross-origin, but we CAN check the frame's contentWindow location // in a try/catch to detect a cross-origin block. try { // This will throw a DOMException if the iframe blocked load // and the error page is on a different origin (which it always is). const href = reportingFrame.contentWindow.location.href; // If we reach here, the iframe loaded same-origin content fine. console.log('[Dashboard] Analytics frame loaded successfully:', href); } catch (crossOriginError) { // DOMException: Blocked a frame with origin "..." from accessing // a cross-origin frame. // This isn't conclusive proof of X-Frame-Options blocking — // it just means the loaded content is cross-origin. // The definitive check is in the Network tab: look for the response // header on the iframe's request, not the parent page's request. console.warn( '[Dashboard] Cannot access iframe content — cross-origin or blocked.', 'Check Network tab for X-Frame-Options or CSP frame-ancestors headers.' ); } }); // ── SERVER-SIDE: how to allow your OWN service to be embedded ───── // This is Node.js/Express — same concept applies to any server. const express = require('express'); // helmet provides security headers including frameguard const helmet = require('helmet'); const embeddableService = express(); // ── Option A: Allow embedding by specific trusted origins only ───── // Using Content-Security-Policy frame-ancestors (preferred, modern) embeddableService.use(function setFrameAncestorsHeader(req, res, next) { // Only allow our dashboard and our partner's domain to embed this service. // Any other origin attempting to embed it gets a browser block. res.setHeader( 'Content-Security-Policy', "frame-ancestors 'self' https://dashboard.thecodeforge.io https://partner.example.com" ); // Also set X-Frame-Options for older browsers that don't support CSP. // SAMEORIGIN = only our own origin can embed it. // If you need cross-origin embedding, CSP frame-ancestors is the only way — // X-Frame-Options can't whitelist multiple origins. res.setHeader('X-Frame-Options', 'SAMEORIGIN'); next(); }); // ── Option B: Block all embedding (default secure posture) ───────── // Use helmet's frameguard for the common case. embeddableService.use( helmet.frameguard({ action: 'deny' }) // This sets: X-Frame-Options: DENY // Nobody can embed your service in an iframe. // Default for anything that doesn't NEED to be embedded. ); // ── CHECKLIST when your iframe shows blank ──────────────────────── /* 1. Open DevTools → Network tab 2. Find the request for your iframe src URL 3. Look at the RESPONSE headers (not request headers) for: - X-Frame-Options: DENY → blocked, no exceptions possible - X-Frame-Options: SAMEORIGIN → only their own site can embed it - CSP: frame-ancestors 'none' → blocked, no exceptions possible - CSP: frame-ancestors 'self' https://... → allowed origins listed 4. If none of those headers exist → the block is something else: - Mixed content (HTTP src on HTTPS page) - The src URL is simply returning a 404 or 500 - A browser extension is interfering */
[Dashboard] Cannot access iframe content — cross-origin or blocked.
Check Network tab for X-Frame-Options or CSP frame-ancestors headers.
DevTools Console error (browser-generated, not your code):
Refused to display 'https://analytics.example.com' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Network tab on the blocked iframe request:
Response Headers:
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options and Content-Security-Policy: frame-ancestors, the CSP directive takes precedence in all modern browsers and X-Frame-Options is ignored. When you're configuring your own service's embedding permissions, set CSP frame-ancestors as the source of truth and add X-Frame-Options only as a fallback for IE11 and ancient Safari. Don't try to juggle both independently — they'll contradict each other and you'll spend an afternoon confused.| Feature / Aspect | sandbox (no tokens) | sandbox with specific tokens |
|---|---|---|
| JavaScript execution | Blocked completely | Allowed if allow-scripts is present |
| Form submission | Blocked completely | Allowed if allow-forms is present |
| Popups / new windows | Blocked completely | Allowed if allow-popups is present |
| Top-level navigation | Blocked completely | Allowed if allow-top-navigation is present |
| Cookie and storage access | Synthetic opaque origin — no access | Allowed if allow-same-origin is present |
| Fullscreen API | Blocked completely | Allowed if allow-fullscreen is present |
| Best used for | Static display-only content (PDFs, HTML docs) | Interactive third-party widgets you don't own |
| Security risk level | Minimum — most restrictive posture | Scales with tokens granted — reason about each one |
🎯 Key Takeaways
- An iframe is a separate browsing context, not a component — it has its own DOM, JavaScript runtime, cookies, and history stack. Treating it like a div with a src attribute is how production security holes get opened.
- Always add the sandbox attribute to third-party iframes and explicitly whitelist only the capabilities you've consciously decided to grant. The six-hour phishing incident I described in the intro was preventable with two attributes and thirty seconds of thought.
- postMessage is the only safe cross-origin communication channel — but it's only safe when both sides verify event.origin before touching event.data. An origin check is one line of code. Skipping it turns your postMessage listener into an open door for any page on the internet.
- A blank iframe is almost never a bug in your code — it's almost always X-Frame-Options or CSP frame-ancestors on the server you're trying to embed. The fix lives in the response headers of the embedded URL, not in your HTML. Check the Network tab first, write zero code until you've confirmed the headers.
⚠ Common Mistakes to Avoid
- ✕Mistake 1: Setting iframe src to an HTTP URL on an HTTPS page — the frame renders completely blank with zero console output in some environments, or in others throws 'Mixed Content: The page was loaded over HTTPS, but requested an insecure frame' — Fix: always use HTTPS src; if the third-party doesn't support HTTPS, don't embed them directly, proxy or re-host the content under your own HTTPS domain.
- ✕Mistake 2: Calling postMessage on the iframe before the iframe's load event fires — the message is sent into the void because the iframe's message listener hasn't been registered yet, resulting in the parent page appearing to do nothing after it sends init data — Fix: have the iframe send an IFRAME_READY message to the parent as the first thing its script does, and have the parent send its initialisation data only in response to that event, never on a timeout.
- ✕Mistake 3: Using
sandboxwith bothallow-scriptsandallow-same-originwhen the iframe src is on the same origin as the parent — the iframe's JavaScript can callframeElement.removeAttribute('sandbox')at runtime and completely remove its own restrictions, rendering the sandbox meaningless — Fix: only combine those two tokens when the iframe src is a different origin; for same-origin sandboxed content, use allow-scripts without allow-same-origin and accept that the frame treats itself as an opaque origin. - ✕Mistake 4: Omitting the
titleattribute on iframe — screen readers announce the frame as 'frame' with no description, causing an automatic WCAG 2.1 Level A accessibility failure that shows up in audits and can create legal liability for public-facing products — Fix: always add a descriptivetitleattribute that explains the iframe's purpose to a user who can't see it, e.g.title='Google Maps showing our London office location'.
Interview Questions on This Topic
- QIf an iframe is sandboxed with allow-scripts and allow-same-origin, and the iframe src is on the same origin as the parent page, what can the iframe's JavaScript do that breaks the sandbox model — and how do you prevent it?
- QYou're building a micro-frontend architecture where six independently deployed React apps need to communicate inside a shell application. When would you choose iframe-based isolation with postMessage over a shared JavaScript module approach, and what are the concrete production trade-offs of each?
- QA user reports that a payment iframe on your checkout page occasionally shows blank in Safari on iOS but works fine on Chrome desktop. Walk me through your exact diagnostic process — which headers do you check, in what order, and what Safari-specific iframe behaviour might be causing this?
- QYour team embeds a third-party analytics iframe on a high-traffic marketing page. Six months later a security researcher reports a stored XSS in the analytics vendor's platform. What blast radius does your site have, what specifically does the sandbox attribute prevent versus not prevent in this scenario, and what would you do differently in the iframe implementation to limit exposure?
Frequently Asked Questions
Why is my iframe showing a blank white box with no error?
The most likely cause is that the site you're embedding has set X-Frame-Options or CSP frame-ancestors headers that block embedding — and some browsers suppress the console error. Open DevTools, go to the Network tab, find the request for your iframe's src URL, and look at the response headers. If you see X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none', the server is refusing to be embedded and there's nothing you can do client-side to override it. The second most common cause is an HTTP src on an HTTPS parent page — mixed content blocks silently in some configurations.
What's the difference between X-Frame-Options and Content-Security-Policy frame-ancestors?
X-Frame-Options is the older header supporting only DENY or SAMEORIGIN — it can't whitelist specific third-party origins. CSP frame-ancestors is the modern replacement that supports a full list of allowed origins and is more precise. When both are present, CSP wins in all modern browsers. Use CSP frame-ancestors as your primary control, add X-Frame-Options only for legacy browser support.
How do I make an iframe responsive so it scales properly on mobile?
The reliable technique is the padding-bottom aspect ratio hack: wrap the iframe in a position: relative container with height: 0 and padding-bottom: 56.25% (for 16:9), then position the iframe absolutely inside it with width and height both at 100%. This makes the container scale with the viewport while maintaining aspect ratio. For arbitrary-height embeds (like chat widgets), set a fixed pixel height on the iframe directly and add max-width: 100% — the padding trick only works cleanly for known aspect ratios.
Can an iframe's JavaScript access the parent page's DOM, or vice versa?
Only if both documents share the exact same origin — same protocol, same domain, same port. If they do, window.parent.document from inside the iframe and iframe.contentDocument from the parent both work. The moment the origins differ by even a subdomain (unless you set document.domain on both sides, which is deprecated and removed in Chrome 106+), the Same-Origin Policy blocks all direct access. Cross-origin iframes must use postMessage for any communication — there is no other legitimate path.
Developer and founder of TheCodeForge. I built this site because I was tired of tutorials that explain what to type without explaining why it works. Every article here is written to make concepts actually click.