iFrame issues in TW. I need to be educated

Developers
#1

After successfully doing Local iframes (no security concern) using PasteUp …

Screenshot 2025-10-03 17.23.47
Screenshot 2025-10-03 17.23.471920×1199 251 KB

I want to use many iframes for online sites.

But I got in a panic on security.

And totally confused by the language (on the web) about iframes and the vast number of options.

So many approaches I don’t know where to start!

Q: For a TW embedding an external site what basic iframe security settings should you start with?

TT

#2

Although both TiddlyTools.com and TiddlyWiki.com allow their pages to be embedded in iframes, there are many other servers that do not permit their pages to be shown inside iframes. Unfortunately, there’s nothing you can do to bypass this restriction, which is defined server-side. If I recall correctly, it may have something to do with “CORS-enabling” the remote site.

-e

1 Like
#3

IFrame embedding is controlled by the website X-Frame-Options header and Content Security Policy (CSP). IOW, a typical user/client/browser cannot influence how those settings are set.

CORS is about cross origin requests where JavaScript (say) on one origin tries to fetch data from another origin – CORS is about data access (XHR, fetch, web fonts, etc.) not embedding sites in iframes.

#4

Thanks @EricShulman & @CodaCoder for your replies.

Now I’m even more worried :slightly_smiling_face:.

My OP was probably not clear enough!

I meant to ask …

What should I add to my ifames in TW to protect myself? (sandbox / permissions etc. in the tag)

Are iframes a rabbit-hole?

TT

#5

Embedding 3rd party sites into your wiki contain 3 risks, that you should be aware of.

  1. Security Risks – as you pointed out
  2. Copyright & Legal Risks
  3. Causing Financial Harm

Add 1) Security Risks

a) Clickjacking & UI Redress Attacks
b) Malicious Redirects of Frame Navigation
c) Browser Exploits & Drive-by Content
d) Information Leakage (if the iframe contains analytics software)
e) Performance and Resource Abuse (eg: Crypto miners)

Many of those risks can be mitigated by using <iframe sandbox> eg:

  • referrerpolicy="no-referrer" and others.
  • By default deny everything and allow as needed

Add 2) Copyright & Legal Risks

Disclaimer: I am not a lawyer so take the following points with a grain of salt.

a) Embedding ≠ Copying (but still risky)

  • When you embed a site via <iframe>, you’re not copying or hosting the content — it’s loaded from the third party’s server.
  • However, you’re redistributing access to that content within your interface, which can still trigger copyright or terms-of-service violations.

b) Terms of Service (ToS)

  • Many sites (e.g., YouTube, Twitter) explicitly allow embedding through official widgets.
  • Others prohibit embedding in their ToS, especially for commercial or derivative use.

Use official APIs instead of your own iframe constructions

c) Copyright & “Public Display”

  • In some jurisdictions, embedding copyrighted works without authorization can still count as a public communication or performance, especially if the original source was not intended for public embedding.

d) Privacy / GDPR Implications

  • Embedding third-party content often loads tracking scripts and cookies (e.g., from Google, Meta, or analytics providers).
  • Under GDPR or CCPA, this could make your wiki the data controller responsible for informing users and obtaining consent.

3) Causing Financial Harm

When you embed 3rd party content from a site that is not prepared for it, it’s possible to hit them financially. eg: Small sites may be billed by traffic volume.

  • Bandwidth theft / “hotlinking” Embedding large images, videos, or documents directly from another site.

  • Unintended traffic spikes A popular wiki could cause sudden heavy load on a small external site.

1 Like
#6

Conclusion

1. Use official embeds or APIs

  • YouTube, Vimeo, Twitter, etc. provide official embed APIs and consent for embedding.
  • Their infrastructure is built for it.

2. Link, don’t embed

  • Instead of loading the entire site in your wiki, use a preview or summary:

3. Self-host or proxy small content

If the content is critical and legally shareable:

  • Download it with permission or if it’s openly licensed (e.g. Creative Commons).
  • Host it yourself or serve a cached snapshot.
  • That way, you serve your own copy and bear the bandwidth.

4. Cache thumbnails or metadata

  • For remote media (e.g., PDFs, YouTube videos), fetch metadata (title, thumbnail, duration) and display that locally.
  • Users can click through to the original source.

5. Check robots.txt / Terms of Use

Before embedding a site, review its:

  • robots.txt or X-Frame-Options header
    • If it sets DENY or SAMEORIGIN, embedding is explicitly forbidden.
  • ToS — many forbid embedding or “public redistribution.”
2 Likes
#7

@pmario I really appreciate your time on this! And the categories (Security / Copyright / Traffic Loading) All useful.

FWIW, the main reason I want to iframe more is to simplify my desktop life. One tab for the 6 sites I use a lot.

You get the idea?

Anyway it is not for any TW I put online.Home use only.

To sort of answer my own question I’ll start with iframes like this …

<iframe 
 name="name" 
  src="URL" 
       sandbox="allow-scripts"
referrerpolicy="no-referrer" 
 width="100%" height="800px"
></iframe>

And add back more permissions as needed?

TT

#8

on this point
i beg to differ
you can use a proxy (server)
to add “CORS-enabling” header!

(potentially the tw server could even add this functionality
… though i didnt have much luck looking for a node-proxy example that works with current node versions…)

1 Like