Codex tools: Log in / create account
Languages: English • 日本語 • (Add your language)
Untrusted data comes from many sources (users, third party sites, your own database!, ...) and all of it needs to be validated both on input and output.
Contents |
The method of data sanitation depends on the type of data and the context in which it is used. Below are some common tasks in WordPress and how they should be sanitized.
intval( $int ) or (int) $int
absint( $int )
Note that many types of XML documents (as opposed to HTML documents) understand only a few named character references: apos, amp, gt, lt, quot. When outputting text to such an XML document, be sure to filter any text containing illegal named entities through WordPress's ent2ncr( $text ) function.
wp_kses( (string) $fragment, (array) $allowed_html, (array) $protocols = null )
wp_kses(). See wp-includes/kses.php for documentation, defaults, etc.
wp_rel_nofollow( (string) $html )
esc_html( $text ) (since 2.8)
esc_attr.
esc_html__ (since 2.8)
esc_html_e (since 2.8)
wp_specialchars( $string, $quote_style = ENT_NOQUOTES, $charset = false, $double_encode = false ) (deprecated since 2.8)
esc_html), as extra protection for older plugins.
htmlspecialchars( $text, ENT_NOQUOTES )
esc_attr (since 2.8)
attribute_escape( $text ) (deprecated since 2.8)
esc_attr__
esc_attr_e
htmlspecialchars( $text, ENT_QUOTES )
esc_js (since 2.8)
js_escape( $text ) (deprecated since 2.8)
esc_url (since 2.8)
clean_url( $url, (array) $protocols = null, $context = 'display' )
clean_url when sanitizing URLs (in text nodes, attribute nodes or anywhere else). Rejects URLs that do not have one of the provided whitelisted protocols (defaulting to http, https, ftp, ftps, mailto, news, irc, gopher, nntp, feed, and telnet), eliminates invalid characters, and removes dangerous characters. $context should be one of the following.
display url db esc_url_raw (since 2.8)
$context = "db", above)
urlencode( $scalar )
urlencode_deep( $array )
$wpdb->insert( $table, (array) $data )
$data should be unescaped (the function will escape them for you). Keys are columns, Values are values.
$wpdb->update( $table, (array) $data, (array) $where )
$data should be unescaped. Keys are columns, Values are values. $where should be unescaped. Multiple WHERE conditions are ANDed together.
$wpdb->update( 'my_table', array( 'status' => $untrusted_status, 'title' => $untrusted_title ), array( 'id' => 123 ) );
$wpdb->prepare( $format, (scalar) $value1, (scalar) $value2, ... )
$format is a sprintf() like format string. It only understands %s and %d, neither of which needs to be enclosed in quotation marks.
$wpdb->get_var( $wpdb->prepare( "SELECT something FROM table WHERE foo = %s and status = %d", $name, // an unescaped string (function will do the sanitation for you) $status // an untrusted integer (function will do the sanitation for you) ) );
esc_sql( $text ) (since 2.8)
$wpdb->escape( $text )
addslashes().
$wpdb->escape_by_ref( &$text )
like_escape( $string )
$string for use in a LIKE expression of a SQL query. Will still need to be SQL escaped (with one of the above functions).
validate_file( (string) $filename, (array) $allowed_files = "" )
$filename represents a valid relative path. After validating, you must treat $filename as a relative path (i.e. you must prepend it with an absolute path), since something like /etc/hosts will validate with this function. Returns an integer greater than zero if the given path contains .., ./, or :, or is not in the $allowed_files whitelist. Be careful making boolean interpretations of the result, since false (0) indicates the filename has passed validation, whereas true (> 0) indicates failure.
Header splitting attacks are annoying since they are dependent on the HTTP client. WordPress has little need to include user generated content in HTTP headers, but when it does, WordPress typically uses whitelisting for most of its HTTP headers.
WordPress does use user generated content in HTTP Location headers, and provides sanitation for those.
wp_redirect($location, $status = 302)
wp_safe_redirect($location, $status = 302)
Many of the functions above in #Output_Sanitation are useful for input validation. In addition, WordPress uses the following functions.
sanitize_title( $title )
sanitize_user( $username, $strict = false )
$strict when creating a new user (though you should use the API for that).
balanceTags( $html ) or force_balance_tags( $html )
tag_escape( $html_tag_name )
is_email( $email_address )
array_map( 'absint', $array )
There are several different philosophies about how validation should be done. Each is appropriate for different scenarios.
Accept data only from a finite list of known and trusted values.
$possible_values = array( 'a', 1, 'good' ); if ( !in_array( $untrusted, $possible_values ) ) die( "Don't do that!" );
// Be careful here with fancy breaks and default actions.
switch ( $untrusted ) {
case 'a' :
...
break;
...
default :
die( "You hoser!" );
}
Reject data from finite list of known untrusted values. This is very rarely a good idea.
Test to see if the data is of the correct format. Only accept it if it is.
if ( !ctype_alnum( $data ) ) die( "Your data is teh suX0R" ); if ( preg_match( "/[^0-9.-]/", $data ) ) die( "Float on somewhere else, jerky" );
Accept most any data, but remove or alter the dangerous pieces.
$trusted_integer = (int) $untrusted_integer; $trusted_alpha = preg_replace( '/[^a-z]/i', "", $untrusted_alpha ); $trusted_slug = sanitize_title( $untrusted_slug );
clean_url() -> esc_url()
sanitize_url() -> esc_url_raw()
wp_specialchars() -> esc_html() (also: esc_html__() and esc_html_e())
attribute_escape() -> esc_attr() (also: esc_attr__() and esc_attr_e())
See also wp_specialchars() vs attribute_escape() ( now esc_attr() ) and quote entity-encoding.