Design Embeds and Third-Party Widgets
Security & Access · embeds, security, components
Updated 2026-08-04
- Treat an embed as a separate product living inside yours. It has its own loading, its own failures, and its own theme, and none of them are under your control.
- Design the states an embed produces before you place it:
- Loading, which can be much slower than the page around it.
- Blocked, because a privacy tool or corporate network refused it.
- Failed, where the provider is down.
- Empty, where the content was removed at the source.
- Reserve the space it will occupy. An embed that arrives late and pushes content down is one of the most common causes of a misplaced click.
- Never let a blocked embed break the page. A meaningful fallback with a direct link is better than an empty rectangle with no explanation.
- Constrain what an embedded frame is allowed to do. Restricting scripts, navigation, and access to the parent page keeps a third-party component from acting as your page.
- Decide whether your own product may be embedded elsewhere, and enforce it. Allowing it invites your interface being framed inside someone else's, which is how clickjacking works.
- Expect requests from your interface to another origin to be refused by the browser unless CORS headers allow them. The visible symptom is a request that silently returns nothing, so build a real error state for it.
- Keep keyboard and screen reader users in mind at the boundary. Focus entering and leaving an embedded region should be predictable, and an embed that traps focus makes the whole page unusable.
An embed is a piece of someone else's product rendered inside yours, and the interface has to be designed for the day it does not arrive.
Related guides
UX Handbook