There are two concepts here:
- validation – making sure data is valid, i.e. an integer is an integer, a date is a date (in the right format etc). This should be done just before saving the data.
- sanitisation – making the date safe for its use in the current context (e.g. escaping SQL queries, or escaping HTML on output).
Validation is, almost universally, solely down to you. You know what data you are asking from a user, and you know what data you are expecting – WordPress doesn’t. Validation would be performed, for example, on the save_post hook before saving it to the database with update_post_meta, or it might be done through specifying a callback function in the Settings API, called just before WordPress saves the data.
Sanitisation is a bit more mixed. When dealing with data that WordPress natively knows about (e.g. a post’s tile) you can be sure that WordPress has already made the data safe. However ‘safe’ depends on context; what is safe for use on a page, is not necessarily safe as an element attribute. Hence WordPress will have different functions for different context (e.g the_title(), the_title_rss(), the_title_attribute()) – so you need to use the right one.
For the most part your plug-in might deal with post meta – or maybe event data from a custom table. WordPress doesn’t know what this data is or what it is for, so it certainly doesn’t know how to make it safe. This is up to you. This is particularly important in using esc_url(), esc_attr(), esc_textarea() etc to prevent malicious input from being able to embed code. Since WordPress knows next_posts() is suppose to print an url to the page, it applies esc_url() – but with post meta, say, it doesn’t know that it stores an url – or what you want to do with it (if printing, esc_url(), if redirecting esc_url_raw(). If in dobut – err on the side of caution and escape it yourself – and do this as late as possible.
Finally – what about saving data? Do you need to make it safe then? As mentioned you do need to make sure data is valid. But if using WordPress API (wp_insert_post(),update_post_meta() etc) then you don’t need to sanitise the data – because when saving data the only sanitising you need to be doing is to escape SQL statements – and WordPress does this. If you are running direct SQL statements (say to read/write data from a custom table) then you should use the $wpdb class to help you sanitise your queries.
I wrote this blog post on data sanitisation and validation which you might find helpful – in it I talk about what’s expected of you in this respect.