Multisite Security

Multisite security

When to use this skill

Use this skill whenever code runs on a WordPress multisite network:

• Using switch_to_blog() to access another site's data.
• Adding network admin pages (network_admin_menu).
• Enumerating sites with get_sites().
• Reading a blog_id from a request parameter or URL.
• Performing actions that affect the whole network vs. a single site.

On multisite, site administrator and network administrator are different roles. Network-level actions require manage_network or manage_network_options, and switch_to_blog() must always be paired with restore_current_blog().

Related: see the capability-permission-checks skill for single-site capability patterns.

Core principles (and why they matter)

1. Site admin != network admin. A site administrator can do almost anything on their own site, but they must not manage network settings or access other sites' data. Network actions need manage_network / manage_network_options.
2. Always pair switch_to_blog() with restore_current_blog(). Forgetting to restore leaves the rest of the request running in the wrong site context, leaking or corrupting data.
3. Re-check capabilities after switching. Capabilities are evaluated in the current site context. After switch_to_blog(), the capability context changes; re-verify current_user_can() or user_can() if you act on the new site.
4. Never trust a blog_id from input. Validate it against allowed sites (e.g., sites the current user belongs to, or the network allowlist) before switching.
5. Keep per-site data isolated. Do not store site A's data in site B's options or tables unless the user explicitly authorized cross-site access.
6. is_super_admin() is for network-level checks only. Prefer current_user_can( 'manage_network' ) for capabilities.

Step-by-step implementation

1. Check is_multisite() before running multisite-specific code.
2. For network admin pages, gate with current_user_can( 'manage_network_options' ).
3. For site actions that read a blog_id from input:
   • Cast to integer.
   • Confirm the site exists (get_site()).
   • Confirm the current user may act on it (user_can( $user_id, 'manage_sites' ) or membership checks).
4. Wrap the operation in switch_to_blog() / restore_current_blog().
5. After switching, re-check capabilities if the action is privileged.
6. Return errors rather than silently failing or defaulting to the current site.

Supporting references

Common AI mistakes / anti-patterns

Mistake 1 — switch_to_blog() with an unvalidated blog id

// ❌ Insecure: any blog id can be requested, including sites the user does not own.
$blog_id = (int) $_GET['blog_id'];
switch_to_blog( $blog_id );
$posts = get_posts();
restore_current_blog();

// ✅ Secure: validate the blog id and the user's relationship to it.
$blog_id = isset( $_GET['blog_id'] ) ? absint( $_GET['blog_id'] ) : 0;
$site    = get_site( $blog_id );
if ( ! $site || ! is_user_member_of_blog( get_current_user_id(), $blog_id ) ) {
    wp_die( esc_html__( 'Invalid site.', 'my-plugin' ), 403 );
}

switch_to_blog( $blog_id );
$posts = get_posts();
restore_current_blog();

Mistake 2 — Forgetting restore_current_blog()

// ❌ Risky: subsequent code runs in the switched context.
foreach ( $blog_ids as $blog_id ) {
    switch_to_blog( $blog_id );
    do_something();
}

// ✅ Secure: restore after each switch.
foreach ( $blog_ids as $blog_id ) {
    switch_to_blog( $blog_id );
    do_something();
    restore_current_blog();
}

Mistake 3 — Using manage_options for a network action

// ❌ Insecure: site admins have manage_options but cannot manage the network.
if ( current_user_can( 'manage_options' ) ) {
    update_site_option( 'my_plugin_network_key', $value );
}

// ✅ Secure: network actions require manage_network / manage_network_options.
if ( ! current_user_can( 'manage_network_options' ) ) {
    wp_die( esc_html__( 'You do not have permission to manage network options.', 'my-plugin' ), 403 );
}
update_site_option( 'my_plugin_network_key', $value );

Mistake 4 — Leaking data after a switch

// ❌ Insecure: data fetched under site B is echoed on site A without re-checking.
switch_to_blog( $blog_id );
$title = get_bloginfo( 'name' );
restore_current_blog();
echo $title;

// ✅ Secure: validate the user may read the target site, then escape output.
if ( ! is_user_member_of_blog( get_current_user_id(), $blog_id ) ) {
    return;
}
switch_to_blog( $blog_id );
$title = get_bloginfo( 'name' );
restore_current_blog();
echo esc_html( $title );

Mistake 5 — Assuming is_super_admin() covers every case

// ❌ Less precise: is_super_admin checks the super-admin list, not a capability.
if ( is_super_admin() ) {
    // do network thing
}

// ✅ Secure: prefer the explicit network capability.
if ( current_user_can( 'manage_network' ) ) {
    // do network thing
}

Correct code examples

A complete network-safe routine that validates a blog id, switches context, and restores it is in references/secure-multisite-operations.php.

Checklist

• Multisite-specific code checks is_multisite() first.
• Network admin actions use manage_network / manage_network_options.
• blog_id values from input are cast to integers and validated.
• The user is confirmed to be a member of / allowed on the target site before switching.
• Every switch_to_blog() has a matching restore_current_blog().
• Capabilities are re-checked after switching sites if the action is privileged.
• Per-site data is not leaked into another site's context.
• is_super_admin() is used only where the super-admin list is the correct gate.

Official references

• is_multisite()
• is_super_admin()
• current_user_can()
• user_can()
• switch_to_blog()
• restore_current_blog()
• get_sites()
• get_current_blog_id()
• network_admin_menu hook
• is_user_member_of_blog()
• Multisite Network Administration