Meta Box

Hi @david.h,

i have been working for the sansitization for long and i understand the position of the developer of the Metabox as well as they need to take into consideration backward compatibility as well.

If you remember i was the one who pointed this out and wanted Metabox to do sanitization out-of-the-box.

You may get surprised to know that ACF still does not apply such sanitization out-of-the-box.

In my opinion, its all fine if a textarea is sanitized using the wp_kses_post instead of more appropriate sanitize_textarea_field.

The reasons being two:
1. Backward compatibility is important, no developer wants to get the support system flooded with angry users who claiming to be something broken due to a new update.
2. Developer who are using this framework should get themselves familiar with the habit of understanding what the framework does out-of-box and they have the option to override the sanitization functions with the help of filter. If they are two lazy to add a line of code for sanitization of their choice, then they should seriously consider their habits of blindly using any framework/plugin found on the wild internet.

Just my two cents.

I know you oppose this approach and more like strict sainitization out-of-box, but please consider all half million developers/users who might be using the textarea field for their custom css code.

Many thanks,

sorry if our opinions does not match.

Regards,

Rao Abid

Hi Anh,

I have not tested it yet, but in my opinion, fields should be sanitized out of the box.

Each field should be sanitized according to its type.

If some developer do not want to use default sanitization and want to allow script tags or other similar dangerous input, he should do it by explicitly explaining that he dont want to use default sanitization.

He may use this sanitization_callback in that case.

I see that your plugin no only skipping sanitization but also not validating input.

e.g. select field input does not check if the provided value is one of the value of options.
(Let me know if its doing so)

I had purchased the bundle before and wanted to use this in my plugin now, but i am not getting comfortable with this practice.

I know you have two problems if you apply the default sanitization in your next version:

Problem 1: Current developers may be using the fields knowing that tags are not stripped off. If you apply default sanitization, their plugins may not behave as expected as all tags will be sanitized.

Problem 2: It may be extra coding hours of debugging and checking.

Grievance: If you do not apply default sanitization, then sites are at risk of XSS at minimum.

Solution: You plan it for the major release and let your developers know that fields will be sanitized automatically according to their type, If they dont want to use default sanitization, they have two options:

1. they can write no_sanitize for the sanitize_callback value and if such value found, you may simple return the value here: https://github.com/wpmetabox/meta-box/blob/e0aa9753a74603fc4a6348f4638c324e48f196f7/inc/sanitizer.php#L51

2. Or, they can provide their own sanitization function in sanitize_callback

In any case, there has to be some default sanitization at all cost.
as @david.h said, it should be white-list approach as compared to blaclist approach.

Let me know your thoughts and plan on this so that i may decide whether to use this tool in my plugin or not.

Regards,

Rao Abid