If you build WordPress plugins, security is not optional. A single vulnerability in your plugin can compromise thousands of sites, destroy your reputation, and open you up to legal liability. The WordPress plugin directory has removed hundreds of plugins over security issues, and the most common vulnerabilities are preventable with basic precautions.
This guide covers the security best practices that every WordPress plugin developer must follow. These aren’t theoretical — they’re the minimum bar for shipping a plugin that won’t put your users at risk.
Input Validation: Never Trust User Input
The first rule of WordPress security is the same as every other web application: never trust user input. Every piece of data that comes from a request — GET parameters, POST data, cookie values, uploaded files — must be validated before you use it.
WordPress provides several functions for sanitizing input. Use sanitize_text_field() for plain text, sanitize_email() for email addresses, sanitize_key() for database keys, sanitize_title() for slugs, absint() for integers, and wp_kses() for HTML content that needs to allow specific tags. Never use $_POST or $_GET directly without sanitization.
The rule is simple: sanitize on the way in, escape on the way out. Validate everything you receive, escape everything you output.
Output Escaping: Preventing XSS Attacks
Cross-Site Scripting (XSS) is the most common vulnerability in WordPress plugins. It occurs when user-supplied data is output without proper escaping, allowing attackers to inject JavaScript into pages that other users will view.
WordPress provides context-specific escaping functions. Use esc_html() when outputting plain text inside HTML tags, esc_attr() for attribute values, esc_url() for URLs, esc_js() for inline JavaScript, and wp_kses_post() for post content that needs to preserve some HTML. For data displayed in HTML attributes, always use esc_attr().
Modern WordPress development increasingly uses React for admin interfaces, which handles escaping automatically. But for traditional PHP-rendered output, manual escaping is essential.
SQL Injection Prevention
SQL injection attacks can allow an attacker to read, modify, or delete your database contents. WordPress’s wpdb class provides prepared statements that prevent SQL injection when used correctly.
Never use $wpdb->query() with concatenated values. Always use $wpdb->prepare() with placeholder syntax. The %s placeholder is for strings, %d for integers, and %f for floats. If you need to use IN() clauses with arrays, use array_fill to generate the right number of placeholders.
Even better than using $wpdb directly is using higher-level WordPress APIs like WP_Query, get_posts(), and get_term_by(). These functions handle SQL injection prevention internally.
Nonces: Protecting Against CSRF
Cross-Site Request Forgery (CSRF) attacks trick authenticated users into performing actions they didn’t intend. WordPress nonces prevent these attacks by adding a one-time token to forms and URLs.
Use wp_nonce_field() in your forms and check it with check_admin_referer() on submission. For URLs, use wp_nonce_url() and verify with wp_verify_nonce(). For AJAX requests, include a nonce in the request data and verify it with check_ajax_referer().
Nonces don’t protect against all CSRF attacks, but they raise the bar significantly. Combined with proper capability checks, they prevent the most common attack vectors.
Capability Checks: Who Can Do What
Every admin page, AJAX handler, and REST API endpoint in your plugin should check that the current user has the required capabilities. Use current_user_can() with the appropriate capability level for each action.
For admin pages registered with add_menu_page() and add_submenu_page(), specify the required capability in the function arguments. WordPress will handle the check automatically. For custom AJAX handlers and REST endpoints, add explicit current_user_can() checks.
Secure Data Storage
Never store sensitive data in plaintext. If you need to store API keys, tokens, or passwords, use WordPress’s encryption functions or better yet, let the user enter them each time rather than storing them at all.
For storing API credentials, use the Options API with encrypted values. WordPress doesn’t provide built-in encryption, but you can use openssl_encrypt() and openssl_decrypt() with a key derived from the site’s AUTH_KEY constant.
Don’t store credentials in plugin files, even as constants. They’ll be visible to anyone who can read your plugin’s source code, and they’ll be exposed if your plugin is submitted to the WordPress.org directory.
Secure File Handling
If your plugin handles file uploads, you must validate file types, check file sizes, scan for malicious content, and store files in a location that’s not directly accessible via the web. Use wp_handle_upload() for standard uploads, which handles many security checks automatically.
For file downloads, never accept a file path from the user. Use an ID or key that maps to a file on your server. This prevents path traversal attacks where an attacker requests files outside your intended directory.
The Bottom Line
WordPress security is not complicated. The rules are well-established: sanitize input, escape output, use prepared statements, verify nonces, check capabilities, and store data securely. Following these practices consistently will prevent 99% of common vulnerabilities.
If you’re publishing on the WordPress.org plugin directory, your plugin will be reviewed for security. Passing that review should be your floor, not your ceiling. Treat security as a continuous practice, not a one-time checklist, and your users will be safer for it.