Question
Trello Power-Up SDK allowedOrigins enforcement gap in local development
Rin Vale
0 reputation · 07 Jul 2026, 19:15 UTC
57.7K views
Loading…
0 reputation · 07 Jul 2026, 19:15 UTC
The Trello Power-Up SDK lets developers configure an iframe URL for the capability interface, and the optional allowedOrigins property is documented as a security control that restricts which domains may embed that iframe. In local development environments, however, the SDK does not appear to enforce this list, and omitting the field leaves the Power-Up loadable from any origin without a runtime warning or error.
This creates uncertainty for teams building Power-Ups on localhost or tunneled domains: it is unclear whether the origin check is intentionally deferred to production, silently ignored in development mode, or simply unvalidated until a later stage. Without knowing the exact boundary, a developer may unknowingly publish a Power-Up that accepts frames from arbitrary domains, exposing the interface to clickjacking or data leakage.
Where does the SDK draw the line between development and production enforcement of allowedOrigins, and what is the expected behavior when the list is absent during local embedding?
35275 reputation · 08 Jul 2026, 07:03 UTC
The Trello Power-Up SDK does not enforce allowedOrigins at iframe load time during local development. When the field is omitted, the expected behavior is fail-open: Trello does not inject additional origin restrictions, and the capability iframe remains loadable from any context that Trello itself permits. The likely boundary is manifest publication or team-enablement, not runtime embedding.
Confirmed: allowedOrigins is an optional manifest property documented as a security control that restricts which domains may embed the capability iframe. It is separate from browser-level framing headers.
Likely explanation (not confirmed without current platform testing): Trello validates allowedOrigins when a Power-Up is published or enabled for a team, rather than on every iframe request. Local development paths—especially localhost and tunneled domains—often use relaxed validation, so the absence of a runtime warning locally does not guarantee production enforcement.
A local Power-Up that loads from an arbitrary origin without complaint may still be blocked in production if the list is present, or it may silently accept frames from any origin if the list is absent. Because the check appears to be deferred, teams can unknowingly publish an interface exposed to clickjacking or data leakage.
trelloallowedOrigins explicitly before publishing. Use exact origin strings (scheme, host, and port) for every environment, including development tunnels.X-Frame-Options or Content-Security-Policy: frame-ancestors on the iframe host. Trello's list does not replace these headers.allowedOrigins list, then attempt to embed the capability from an unauthorized origin and observe whether Trello blocks the load.This analysis assumes current SDK behavior as of late 2026 and relies on general platform patterns. The exact validation boundary—whether it occurs at manifest upload, team enablement, or first production load—has not been confirmed against live Trello infrastructure and should be treated as unverified.
If your local tunneled domain rotates between sessions, the recommendation shifts from "add the current origin to allowedOrigins" to "use a stable domain for any test intended to mirror production." Is your tunnel origin stable, or does it change on reconnect?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.