Sanitization of Fields input

Hi David,

Thanks for your feedback. Yes, I want to complete this thing as it's important and I don't want to postpone at the middle.

Regarding your feedback:

1. I think sanitize_textarea_field is too limited. It seems fine with the function name, but people usually use it for HTML content. I'm using wp_kses_post, which I think is okay.
2. Adding params for wp_kses_post can be done. But it will make the code more complicated in both plugin's side and developer's side. I think in this case, developers can do that easier with a custom sanitize callback like this:

'sanitize_callback' => function( $value ) {
    $allowed_tags = [];
    return wp_kses( $value, $allowed_tags );
}

1. I'm thinking about this, too. Need to find a good way to implement that without breaking things.
2. That's available via custom sanitize_callback param (see the example above). Developers can define their own sanitize callback or bypass the sanitization with this code:

'sanitize_callback' => function( $value ) { return $value; }

Hi David,

Your feedback is great and that's exactly what I'm looking for. My reply above was just a discussion about your ideas.

I'll consider your suggestions. Thanks.

I was able to bypass the sanitization of the textarea field in the sanatize.php file

/**
'textarea' => 'wp_kses_post',
*/

but of course when the metabox plugin gets updated that file will be overwriten.

I'm not a coder, could you provide me a code snippet I can paste into the child theme functions.php file to disable sanitization for the textarea field?

Thanks, love your plugin and the support you provide.

Pieter

Is there a reason textarea is using wp_kses_post over sanitize_textarea_field?

Hi Long/Anh,

Normally I would not reply to an ostensibly "resolved" thread, but this is security related and should not be ignored any longer. There needs to be a solution to the issue you are grappling with which, primarily, seems to be allowing developers to embed HTML in a page using Metabox fields.

This should be done using a specific, preferably dedicated, field type (e.g. HTML or custom) where the sanitation is more relaxed - i.e. wp_kses_post.

The average user should not have to consider whether Metabox has correctly handled sanitization for their custom fields. So, when they create a textarea field (for it's intended purpose - text), this should not be open to abuse by unscrupulous users or bots posting HTML, scripts or suchlike.

Thus, as has been suggested several times in this post, all Metabox fields should be sanitized using the most appropriate WordPress function - i.e. in this instance, sanitize_textarea_field.

Please can you come up with a solid solution.

Hi guys,

Rao pointed some valid point over the decision.

I want to clarify that:

sanitize_textarea_field is the best for textarea field from the developer point of view and I agree with that. However, there are some reasons we consider using wp_kses_post as the default sanitize callback:

First: from user point of view, as David said, they don't know what happen behind the scene. And in fact, they do use textarea for storing HTML a lot! Something like footer credit or some text for the top bar. Some even use it for embeded videos. We see this behavior all the time. So we decide to use wp_kses_post to bring more comfort to users. Note that, this doesn't mean less secured! Both wp_kses_post and sanitize_textarea_field are secured (and that's the main point of the sanitization). We need to keep balance between comfort and strictness.

Second: as Rao said, backward compatibility is important. Being activated on 500k sites, we don't want to get thousands of complaints and support topics for the same broken textarea. In fact, there are many topics here and on wordpress.org forums asking why their textarea field not working as expected (because they store embeded videos HTML code).

I can say, if I build Meta Box again from scratch, sanitize_textarea_field might be the best choice. But at this time, wp_kses_post is a better choice.

And remember, they're both secured. That's the main point.

Hi David,

Allowing HTML in textarea doesn't mean less secured. In fact, it's the recommended way to sanitize content that contains HTML. WordPress is smart enough to filter the allowed HTML tags based on the role of the current user. Using it actually prevents websites from being compromised. So, I think no problems using it on the frontend.

PS: The topic is always open for discussion.