How should dynamic blocks handle escaping inner blocks?

[fabiankaegy]

When a block is using dynamic rendering (defines a render_callback in PHP) and has inner blocks, it gets the html content of these inner blocks passed in via the second parameter of the render_callback function.

register_block_type_from_metadata(
    __DIR__,
    [
        'render_callback' => function ( $attributes, $content, $block ) {
            // how should the $content variable get escaped when it gets output? 
        }
    ]
);

The question is how this $content parameter should be escaped. Looking at the WordPress VIP Coding Standards for example it states: https://docs.wpvip.com/technical-references/security/validating-sanitizing-and-escaping/#h-always-escape-late

Always escape late

It’s best to do the output escaping as late as possible, ideally as data is being outputted.

But when you run wp_kses_post( $content ) that breaks functionality like the core embed block. Some filters like the oembed system in WordPress get applied to the block before it gets passed into a parent block.

We've also tried to apply the the_content filters on the block content to get the oembed to work again but that has no success.

echo apply_filters( 'the_content', wp_kses_post( $content ) );

Looking at the actual source code of this does not really answer the question which filters get applied either: https://github.com/WordPress/wordpress-develop/blob/ef404e2599b7e9ff0a9568d0f7348731e89f5f14/src/wp-includes/class-wp-block.php#L205-L304

Looking at some of the core blocks the $content string is not escaped and just output as is from the parent blocks. This always gets flagged in VIP Code Reviews for example and there isn't any clear guidance on what the best practice here should be.
Thanks in advance for any thoughts on this :)

[manzurahmed]

I am also facing the same problem in Gutenberg development. Is there any solution to escape the $content attribute? $content always gets caught by the WordPress Plugin Check plugin?
When I use esc_html() or esc_attr() function on $content, the Front-end outputs the raw HTML code, not the actual visual representation of my Gutenberg plugin.

[g-elwell]

I see this is an old discussion, but did you ever form an opinion on this @fabiankaegy? 🙂

I have been wondering the same thing recently, for the exact same reasons you listed - embed blocks as inner blocks of a custom block. I'm forming the opinion that parent blocks shouldn't be responsible for escaping the output of their inner blocks.

As far as I can tell, block content is deemed 'trusted' within core, and I suppose blocks should be responsible for escaping their own attributes, etc. Then, we're reliant on the unfiltered_html capability to prevent users from adding malicious code into posts.

This doesn't quite sit right with me, but I'd also like to avoid using custom wp_kses arguments, which would need to allow iframe and script tags through anyway to prevent breaking embed block functionality, making them far less safe.

[t-hamano]

parent blocks shouldn't be responsible for escaping the output of their inner blocks.
blocks should be responsible for escaping their own attribute

I agree with this. I'm curious why blocks have to handle escaping for their inner blocks.