[herewithme]

Fixes #24

What

• allow values are filtered against a Permissions Policy feature allowlist: accelerometer, autoplay, clipboard-write, encrypted-media, fullscreen, gyroscope, picture-in-picture, web-share.
  • Unknown or sensitive directives (camera, microphone, geolocation, display-capture, payment…) are dropped.
  • Origin lists are removed, so each kept feature defaults to the iframe src origin.
  • If nothing remains, the attribute is omitted.
• The same filtering is applied on the front end (BlockRenderer::sanitize_allow_value()) and in the editor preview (sanitizeAllowValue() in utils.js).
• The obsolete allowpaymentrequest is removed from the allowlists.
• The deprecated save stays unfiltered on purpose. It must reproduce the old markup for block validation and is never mounted.
• New filter blockparty_iframe_allowed_features (front end only). The editor preview uses the static list, so features added through the filter are not shown in the preview.

Tests

No automated test suite exists in the repo, and CI will run phpcs and eslint. Checks run locally:

• php -l includes/BlockRenderer.php
• PHP harness with minimal WP stubs:
  • camera *; microphone *; geolocation *; display-capture * → allow omitted
  • Fullscreen; autoplay https://evil.example; camera; autoplay;; encrypted-media 'self' → allow="fullscreen; autoplay; encrypted-media"
  • allowpaymentrequest dropped
  • allowfullscreen kept
• Node checks of sanitizeAllowValue(), convertAttributesToProps() and convertAttributesToRawProps() (raw output unchanged)

Review notes

• Behaviour change: existing blocks with allow="camera; microphone" (for example, some video-call embeds) lose those permissions. Sites that need them can extend the list with the filter.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes security-sensitive iframe permission delegation and alters rendered markup for existing blocks with broad allow values, though the net effect is restrictive rather than expanding trust.

Overview
Hardens how the iframe block outputs the allow Permissions Policy attribute on the front end and in the editor preview, so contributors without unfiltered_html cannot delegate sensitive capabilities to embedded documents.

allow values are parsed and filtered to a fixed low-risk feature set (accelerometer, autoplay, clipboard-write, encrypted-media, fullscreen, gyroscope, picture-in-picture, web-share). Directives such as camera, microphone, geolocation, display-capture, and payment are dropped; origin lists are stripped so kept features apply only to the iframe src origin. If nothing remains, allow is omitted. PHP adds sanitize_allow_value() in BlockRenderer and a blockparty_iframe_allowed_features filter to extend the list on rendered output; sanitizeAllowValue() in utils.js mirrors this for convertAttributesToProps() (static list in the editor preview).

The obsolete allowpaymentrequest attribute is removed from the PHP/JS attribute allowlists and boolean-attribute handling. CHANGELOG documents the unreleased security changes.

Compatibility: blocks that stored permissive allow strings (e.g. video-call embeds) will render with fewer permissions unless a site extends the PHP filter.

^{Reviewed by Cursor Bugbot for commit fa1abba. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Rahe]

is_allowed_iframe_attribute(): the aria-* / data-* regex can be replaced with str_starts_with() (PHP 8.0+, plugin requires 8.1). The first regex already validates the name syntax, so only the prefix check is needed:

return in_array( $attribute_name, self::ALLOWED_ATTRIBUTES, true )
	|| str_starts_with( $attribute_name, 'aria-' )
	|| str_starts_with( $attribute_name, 'data-' );

Same in utils.js with name.startsWith().

---

Generated by Claude Code