4

I recently wrote a plugin and now I'm backtracking a bit to sanitize any and all user input. I know that I should sanitize anything that comes from $_GET or $_POST as a user can insert malicious scripts into that.

I also am sanitizing anything I'm calling via get_options that the user inputted just to be safe (not sure if the options.php API sanitizes but that's another question).

But what about cookies? Do these need to be sanitized? If so how? Here is my function:

$get_cookie_check = wp_kses($_GET['view_full_site'],null); //sanitize user input
$site_url  =  site_url(); 
$domain  =  parse_url($site_url, PHP_URL_HOST);
    if($get_cookie_check =='true'){
        //set the cookie
        setcookie("nifty_cookie", 1, time()+86400, "/", $domain);
        $_COOKIE['nifty_cookie'] = 1;
    }
}
//cookie variable
$full_site_cookie= $_COOKIE['nifty_cookie']; 

I'm not thinking I need to sanitize anything here because I'm the one setting the cookie value (in this case to 1) via PHP. Is this a correct thought?

1 Answer 1

3

This maybe just a personal distinction but I consider:

  • data validation to mean is the data 'correct'? Is it what we expect?
  • data sanitisation to mean is the data *safe to use *

Though there can be some blurring, typically data validation will only occur when a user-input is taken, or some data is obtained and we wish to make sure its 'correct' before we use it. This might be if we expect an integer, is it an integer, if its we expect a date, is it of the correct form? The options API allows you to define a validation callback for your settings.

Data sanitisation is about making the data safe. And this should be done anytime you use the data. Best practise is to sanitise late, i.e. only sanitise just before you use it. Typically you don't have to worry about this for saving to the databse if you're using the api functions such as update_option(), update_post_meta() etc (but you do when handling the database directly).

But what is safe depends on context. Is the data intended to be used as an url, in a text input, in text-area, or an SQL query?

So it depends you how you intend to use the variable $full_site_cookie on how you should sanitise it.


In the above you use $get_cookie_check = wp_kses($_GET['view_full_site'],null);. wp_kses() is expensive and it seems you expect the $_GET['view_full_site'] to be 'true'. Why not just be strict with it:

$get_cookie_check = ( !empty( $_GET['view_full_site'] ) )
                      && 'true' == strtolower( $_GET['view_full_site'] ) );
//$get_cooke_check is now a boolean.
4
  • That helps as far as $_GET[] but I'm still a little confused about the $_COOKIE is there a way for a user to change/update this value with insecure/invalid data. If so then I'll need to sanitize it, correct? Aside: I feel that just because using get_option/update_option should be safe it shouldn't slow it down that much to sanitize a second time.
    – Brooke.
    Commented Aug 4, 2013 at 3:32
  • update_option() is safe to update data to the (options table) database. But data there could be dangerous to use in a textarea element, for example. But yes, $_COOKIE is set by the browser, so it can't be trusted. So if you're saving $full_site_cookie with update_option() you don't need to do anything. But if you then retrieve it from the options table to display on a page, you should use esc_html(). Commented Aug 4, 2013 at 8:40
  • I never am actually saving the $_COOKIE into the database. Just checking for the cookie and then running a script based on its value. So do I need to sanitize it at all if it's not being saved to the database?
    – Brooke.
    Commented Aug 4, 2013 at 9:21
  • 1
    It would depend on how you're using it. If its just used in a conditional then no, but if you're using as part of a script or displaying it in some format then yes. Commented Aug 4, 2013 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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