Security for Developers

WordPress core has a security team, coordinated disclosure and automatic minor releases backported to older branches. Plugins and themes run with the full privileges of core (any PHP in an active plugin can read the database, write files and act as any user) without that process, and almost every WordPress compromise starts in their code. The flaws fall into a handful of patterns, mapped here to the OWASP Top 10 (2025 edition):

Data crossing a trust boundary passes a fixed sequence: authorize the request, unslash, validate (reject what is not in an allowed form), sanitize (clean into a safe form), store, and escape for the exact output context as late as possible, so that values stored by an older version, another plugin or a database edit are still safe.

Validation answers yes or no and is the stronger option whenever the valid values are known; sanitizing transforms free text. A value sanitized on input is still escaped on output, because the output context decides which characters are dangerous.

Authorization in WordPress is capability-based. A role is only a named set of capabilities, so code checks capabilities, never role names: current_user_can( $capability, $object_id ) for the current user and user_can() for another one.

is_admin() is often mistaken for authorization. It returns true when an admin screen is loading, including admin-ajax.php and admin-post.php, which every logged-in user can reach; it says nothing about the user. is_user_logged_in() is true for a Subscriber. Neither replaces a capability check. On the test site, map_meta_cap( 'edit_post', $user_id, 4 ) for a published book written by someone else returns edit_others_posts,edit_published_posts, so current_user_can( 'edit_post', 4 ) is true for the Editor maria.editor and false for the Author tom.author.

A nonce is WordPress’s protection against cross-site request forgery (CSRF): a page on another site that makes a logged-in user’s browser submit a form, load a URL or call an endpoint. The browser sends the user’s cookies, so a capability check alone passes; the nonce proves that the request came from a page WordPress generated for that user.

Despite the name, a WordPress nonce is reusable: a hash of the action, user ID, session token and time tick, valid 24 hours by default (two 12-hour ticks; filter nonce_life). Another user’s or session’s nonce fails; logged-out visitors all share user ID 0. A nonce is not authorization: it shows that the user meant to send the request, not that they may, and nonces printed in pages can leak, so every handler also checks current_user_can(). Include the object ID in the action (lumen_feature_book_42) so a nonce for one book cannot be replayed against another.

Custom code calls wp_verify_nonce(), which returns 1 (first 12 hours), 2 (second 12 hours) or false. REST requests authenticated with application passwords or OAuth need no nonce, since there are no cookies for another site to ride on; see Authentication and Login API.

WordPress adds slashes to $_GET, $_POST, $_COOKIE, $_SERVER and $_REQUEST at load time (wp_magic_quotes()), so superglobals are always read through wp_unslash() first, or O'Reilly is stored as O\'Reilly. The slashes are not a defense: they do nothing in numeric SQL or HTML contexts and disappear as soon as code unslashes, as it must. REST parameters and get_option() values are not slashed.

Validate against an allow-list wherever possible (a strict in_array(), a preg_match() for an ISBN, get_post_type() equal to lp_book, is_email()) and reject invalid input with an error rather than silently "fixing" it.

Escape every dynamic value at the moment it is printed, with the function for that context. Late escaping makes each echo statement show that its value is safe, which reviewers and the coding-standards sniffs can check without tracing the data back.

Source: Common APIs Handbook: Escaping Data

wp_kses_post() kept <b> but dropped the event handler. Users with unfiltered_html (Administrators and Editors, only Super Admins on Multisite) may save any HTML in post content, which still does not make it safe elsewhere. Translations are input too, hence esc_html__() rather than __().

$wpdb runs whatever SQL it is given. Every query containing a variable goes through $wpdb->prepare(), which takes sprintf()-style placeholders, never quoted by hand: %s (string, quoted and escaped), %d and %f (integer and float), %i (identifier such as a table or column name, wrapped in backticks; added in WordPress 6.2 and detectable with $wpdb->has_cap( 'identifier_placeholders' )) and %% (a literal %).

LIKE wildcards belong in the argument, with the user’s part passed through $wpdb->esc_like() so that a typed _ or % matches literally:

Source: Code Reference: wpdb::prepare()

%d turned 5 OR 1=1 into 5; % signs stay masked until the query runs, hence remove_placeholder_escape().

The Lumen Press catalogue team wants a "Catalogue tools" screen: search books by ISBN, mark one as featured with a short note, and return to a given page. The first version works and contains five classic vulnerabilities. It is attacked and then fixed below; it must never run anywhere but a disposable local site.

admin-ajax.php. Handlers are registered on wp_ajax_{$action} (logged-in users of any role) and wp_ajax_nopriv_{$action} (visitors). Some older books post from jQuery with no nonce to a handler that checks neither a nonce nor a capability. The handler below does both, and the nonce travels to the script with its data:

Source: Plugin Handbook: AJAX

Source: Plugin Handbook: AJAX

The wrapper receives jQuery as $ (WordPress loads jQuery in noConflict mode, so a bare $ is undefined) and inserts text, never HTML. Without the nonce the handler answers -1 (403), with it {"success":true,"data":{"count":2}}, and logged out 0 (400, no nopriv handler). New code prefers REST; see JavaScript, AJAX and Heartbeat.

REST API. Every route needs a permission_callback: leaving it out triggers a _doing_it_wrong notice since WordPress 5.5, and __return_true is only for routes meant to be public. Arguments are described with JSON Schema so that core validates them before the callback runs:

Source: REST API Handbook: Adding Custom Endpoints

Source: REST API Handbook: Authentication

The first request had valid login cookies but no wp_rest nonce, so it ran as user 0 and got 401; the Author with his own nonce gets 403. A pitfall: a custom sanitize_callback (such as absint) replaces the default rest_parse_request_arg(), which is what validates against the schema; with it, book=abc silently became 0 and reached the callback. See REST API: Extending It.

Some older books register a Customizer setting without a sanitize_callback and echo get_theme_mod() straight into the template. Whoever can save the setting, or any code that writes the theme mod, then controls raw markup on every page. Sanitize when the setting is saved and escape when it is printed:

Source: Theme Handbook: Customizer Objects

Source: Code Reference: get_theme_mod()

URLs pair esc_url_raw with esc_url(), colours sanitize_hex_color with esc_attr(); see Customizer API.

An upload handler decides what ends up inside the web root. Check upload_files and a nonce as for any state change, then let WordPress move the file with wp_handle_upload() (form uploads), wp_handle_sideload() (files already on the server) or media_handle_upload() (which also creates an attachment). They run wp_check_filetype_and_ext(), which compares the extension with the real content, and sanitize and de-duplicate the file name. Pass a restricted mimes list; otherwise the site-wide get_allowed_mime_types() (filter upload_mimes) applies, which must never gain php, svg or html. Never trust the browser’s type field or write uploads to a path built from input.

Source: Code Reference: wp_handle_upload()

The same checks in a wp eval-file script, through wp_handle_sideload() (same code path, for files not just posted):

Source: Code Reference: wp_check_filetype_and_ext()

The PHP file named .jpg was refused although the client claimed image/jpeg, and the PNG named .jpg was stored under its real extension. Posted to the handler above, the PNG is stored (302 back to the tools screen) and the PHP file gets "Sorry, you are not allowed to upload this file type." (400). The web server should also refuse PHP in uploads/ (Web Servers: Apache and nginx).

Server-side request forgery (SSRF) happens when the server fetches a URL that a user controls (an importer, a webhook target, a "fetch the cover from this address" field) and so reaches the database container, an internal admin panel or the cloud metadata service at 169.254.169.254, which hands out credentials. wp_remote_get() fetches anything. wp_safe_remote_get(), wp_safe_remote_post(), wp_safe_remote_head() and wp_safe_remote_request() set reject_unsafe_urls, so wp_http_validate_url() checks the URL and every redirect target: http or https only, no credentials in the URL, no host resolving to a loopback, private, link-local (cloud metadata), carrier-grade NAT, documentation, multicast or reserved address (unless it is the site’s own host or http_request_host_is_external allows it), and port 80, 443 or 8080 only (filter http_allowed_safe_ports; a public host on port 8443 is refused too).

Source: Code Reference: wp_safe_remote_get()

web is the test stack’s web server container: the plain function reached it (the 301 is WordPress’s canonical redirect), the safe one refused before connecting. On a cloud VM the metadata call would have returned data. Use the safe variants for every URL that is not a constant, and treat responses as untrusted input (validate, escape, short timeout, limit_response_size). See HTTP and Filesystem APIs.

wp_safe_redirect() passes the target through wp_validate_redirect(), which keeps relative paths and the site’s own host and replaces anything else with the fallback: on the test site https://attacker.example/ and //attacker.example/ became the fallback, /wp-admin/edit.php?post_type=lp_book passed. Follow every redirect with exit;, and allow legitimate external targets with the allowed_redirect_hosts filter, never by going back to wp_redirect().

Further corrections are collected in Where Older Books and Tutorials Are Outdated.