I have a custom meta box with a textarea where users can drop in vimeo embed code.

Should I sanitize this code before I update_post_meta, and, if so, how should I go about it? I don't want to strip out important information (like the iframe)...I just want to make sure nothing malicious is getting entered.


You need to add a custom validation/sanitization callback, and hook it into publish_post (and/or draft_post and/or future_post, as applicable). For example:

function wpse_44807_update_custom_post_meta() {
    // Globalize the $post object
    global $post;
    // If our custom post meta key is set, sanitize it;
    // otherwise, return false
    $my_post_custom = ( isset( $_POST['_my_post_custom'] ? wp_filter_nohtml_kses( $_POST['_my_post_custom'] ? false );
    // Now, delete or update our custom post meta key
    if ( false == $my_post_custom ) {
        delete_post_meta( $post->ID, '_my_post_custom' );
    } else {
        update_post_meta( $post->ID, '_my_post_custom', $my_post_custom );
add_action( 'publish_post', 'wpse_44807_update_custom_post_meta' );
add_action( 'draft_post', 'wpse_44807_update_custom_post_meta' );

Note that I'm sanitizing using the wp_filter_nohtml_kses() filter, which would be appropriate if you are expecting, say, a video ID or something similarly alpha-numeric. Your choice of sanitization will change, depending on the type of expected input.

Also: I'm using an underscore-prefixed custom post meta key, which is appropriate if you're defining a custom post meta box for your custom post meta key. (The underscore prefix hides this meta key from the generic "custom field" meta box drop-down.)


update_post_meta() will sanitize it for database insertion for you. What you really need to be watching for is malicious HTML and such that would affect the output. For that you will need a regex or some other means of comparison to a known/desired format. To handle that I would recommend only accepting the video ID or something of that nature where you can strictly control how the output is done, rather than allowing the user to supply you with the iframe and such.

  • Actually, update_post_meta() doesn't do any validation or sanitization; it simply replaces one DB value with another. – Chip Bennett Mar 7 '12 at 19:42
  • are iframes considered malicious? Because I need that for the vimeo embed! – redconservatory Mar 7 '12 at 19:47
  • @ChipBennett I believe you're incorrect. update_post_meta() calls update_metadata(), which inserts the data with $wpdb->update, which does data sanitization as per this page in the codex. I could be wrong...and by all means correct me if I am, but it wouldn't make any sense to me to do all the stripslashes() and such that is done on the data if it was expecting sanitized data, as that would unsanitize it. – mor7ifer Mar 7 '12 at 19:54
  • @m0r7if3r $wpdb->update doesn't sanitize (or validate) data; rather, it escapes data. Data escaping may or may not be sufficient, depending on the expected data. – Chip Bennett Mar 7 '12 at 19:58
  • @redconservatory iframes are not inherently malicious, but I could very easily send an <iframe> that DIDN'T contain a vimeo embed, and, barring some pretty brilliant filtering on your part, it would be displayed on your site. On the other hand, if YOU create the iframe from a video id, then you know it will be in one format with VERY little deviation. Even still, you'll need to filter the users' input for malicious stuff, but that should be as easy as checking length and ensuring that you're only receiving alphanumerics. – mor7ifer Mar 7 '12 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.