wordpress

WordPress

WordPress has its own way of doing everything, and fighting it produces brittle, insecure code. Three WP-specific disciplines carry most of the safety: nonces (intent), capability checks (authorization), and sanitize-in / escape-out (data). The PHP language craft is owned by php; this is the WordPress layer on top.

Scan a plugin/theme for the WordPress security footguns: python3 scripts/scan_wp_smells.py wp-content/plugins/myplugin/**/*.php

Hooks — the entire extension model

// actions DO something; filters TRANSFORM and must return
add_action('init', 'myplugin_register');
add_filter('the_content', function (string $content): string {
    return $content . '<p>Appended.</p>';   // a filter MUST return the value
});

You extend WordPress by hooking, never by editing core. An add_filter callback that forgets to return silently blanks the content. Register everything on the right hook (init, wp_enqueue_scripts, rest_api_init) — running too early means core isn't loaded yet. Detail → references/wp-development.md.

The security trinity (every request handler)

function myplugin_save(): void {
    // 1. NONCE — the request came from your form, not a forged one
    if (!isset($_POST['_wpnonce']) || !wp_verify_nonce($_POST['_wpnonce'], 'myplugin_save')) {
        wp_die('Bad nonce');
    }
    // 2. CAPABILITY — this user is allowed to do this
    if (!current_user_can('edit_posts')) {
        wp_die('Forbidden');
    }
    // 3. SANITIZE input, ESCAPE output
    $title = sanitize_text_field($_POST['title'] ?? '');
    update_post_meta($post_id, 'title', $title);
}

All three, every time. A nonce without a capability check stops forgery but not an under-privileged user; a capability check without a nonce is CSRF-able; neither without sanitizing is injection. Detail → references/wp-security.md.

Database — $wpdb->prepare, always