Repository navigation
Security: iframe allow attribute lets contributors delegate sensitive browser permissions #24
Description
Summary
The block renders the allow attribute verbatim, apart from HTML escaping (includes/BlockRenderer.php, ALLOWED_ATTRIBUTES and build_iframe_attribute_string(); same allowlist in src/blockparty-iframe/utils.js). The plugin lets users without unfiltered_html (contributors, authors, and non-super-admin administrators on multisite) embed iframes. Because of this, they can grant powerful features to any third-party page they embed, for example:
allow="camera *; microphone *; geolocation *; display-capture *"
Visitors' browsers then let the framed page request those features. Chromium attributes delegated permission prompts to the top-level site, so the request appears to come from the WordPress site itself. The attribute is not shown in the block's visual UI, so a reviewer is unlikely to notice it.
Severity
Low. It requires a malicious or compromised editorial account, and each visitor still has to accept the browser prompt. It was found during an internal security review of 1.2.1. Version 1.2.1 already fixed the stored XSS, which the review confirmed.
Expected
Only low-risk features can be delegated (fullscreen, autoplay, encrypted-media, picture-in-picture, …). Origin lists are dropped, so features only apply to the iframe src origin. The obsolete allowpaymentrequest is no longer rendered.
Activity
Rahe commentedon Nov 6, 2026
Suggestion: render the editor preview with
ServerSideRenderinstead of rebuilding the iframe in JS. Both renders would then go throughBlockRenderer, so attribute filtering lives only in PHP:blockparty_iframe_allowed_features(or any future filter) applies to the preview too;convertAttributesToProps(),sanitizeAllowValue()and the JSALLOWED_FEATUREScan be removed.JS checks left in
parseIframeCode()andisSafeIframeUrl()would only be input UX, not a security boundary.Generated by Claude Code
herewithme commentedon Nov 11, 2026
Thanks, applied in 123e26a (PR #25), following this suggestion:
ServerSideRender(default import, so it still works on WordPress 6.7–6.8) withskipBlockSupportAttributes, so it goes throughBlockRendererlike the front end.blockparty_iframe_allowed_featuresapplies to the preview too.convertAttributesToProps(),sanitizeAllowValue()and the JSALLOWED_FEATURESare removed.parseIframeCode()andisSafeIframeUrl()stay, documented as input UX only.editor.scssmakes the nested server-rendered markup fill the block wrapper, so the defaultaspect-ratio: 1doesn't fight the block's dimensions.One behaviour change: the preview shows the saved attributes, not unconfirmed edits typed in the placeholder.
Not yet checked in a running editor (height, aspect ratio, loading state); worth a look during review.
Generated by Claude Code