Największą luką bezpieczeństwa w większości stron WordPress nie jest wtyczka. Jest nią nadawanie klientowi dostępu “Administratora”, gdy potrzebuje tylko edytować wpisy.

Albo co gorsza, danie “Stażyście” możliwości przełączania motywów (switch_themes).

WordPress posiada potężny system Kontroli Dostępu (ACL) wbudowany w rdzeń. Nazywa się Role i Uprawnienia (Roles & Capabilities). W tym przewodniku wyjdziemy poza domyślną rolę “Redaktora” i nauczymy się projektować bezpieczne uprawnienia.

1. Koncepcje: Rola vs Uprawnienie (Capability)

Uprawnienie (Capability/Cap): Konkretne zezwolenie na zrobienie jednej rzeczy.
- Przykład: edit_posts (edycja wpisów), publish_pages (publikacja stron), install_plugins (instalacja wtyczek).
Rola (Role): Zbiór uprawnień.
- Przykład: Editor (Redaktor) = edit_posts + publish_posts + manage_categories (ale NIE install_plugins).

Złota Zasada: Zawsze sprawdzaj Uprawnienia, nigdy Role.

// ❌ ŹLE
if ( current_user_can( 'administrator' ) ) { ... }

// ✅ DOBRZE
if ( current_user_can( 'manage_options' ) ) { ... }

2. Tworzenie Własnej Roli

Powiedzmy, że masz “Managera Sklepu”, który musi zarządzać Produktami, ale nie powinien dotykać Twojego Motywu ani Wtyczek.

function wppoland_add_store_manager_role() {
    add_role(
        'store_manager',
        'Manager Sklepu',
        [
            'read'         => true,
            'edit_posts'   => true,
            'upload_files' => true,
            'manage_woocommerce' => true, // Customowe uprawnienie
        ]
    );
}
// Uruchom TYLKO RAZ (np. przy aktywacji wtyczki/motywu)
// add_action( 'init', 'wppoland_add_store_manager_role' );

Ważne: Role są zapisywane w bazie danych (wp_options > wp_user_roles). Nie musisz uruchamiać add_role przy każdym ładowaniu strony. Uruchom raz przy wdrożeniu.

3. Dodawanie Uprawnień do Istniejących Ról

Czasami chcesz po prostu pozwolić “Redaktorowi” na edycję Menu (czego domyślnie nie może robić).

function wppoland_upgrade_editor() {
    $role = get_role( 'editor' ); // Pobierz obiekt roli 'editor'
    if ( $role ) {
        $role->add_cap( 'edit_theme_options' ); // Pozwala na edycję Menu i Widgetów
    }
}
// Uruchom raz

4. Odzyskiwanie Dostępu: Resetowanie Ról

Jeśli wtyczka zepsuła Twoją bazę danych lub przypadkowo usunąłeś rolę ‘Administratora’ (zdarza się!), potrzebujesz twardego resetu.

Ten skrypt przywraca domyślną architekturę ról WordPress.

function wppoland_reset_roles() {
    // Zabezpieczenie przed przypadkowym uruchomieniem
    if ( ! isset( $_GET['reset_roles_secret_key'] ) ) return;

    require_once( ABSPATH . 'wp-admin/includes/schema.php' );
    populate_roles();
    
    echo "Role Zostały Zresetowane.";
    exit;
}
add_action( 'init', 'wppoland_reset_roles' );

5. Najlepsze Praktyki Bezpieczeństwa 2026

A. Nie używaj nazwy użytkownika ‘admin’

Ataki Brute Force celują w ID użytkownika 1 lub nazwę ‘admin’.

B. Mapuj Meta Capabilities

Używając Custom Post Types, nie używaj po prostu edit_posts. Mapuj granularne uprawnienia:

register_post_type( 'book', [
    'capability_type' => 'book',
    'map_meta_cap'    => true, // Klucz do precyzyjnej kontroli
] );

Teraz możesz dać użytkownikowi uprawnienie edit_books bez dawania mu edit_posts (które pozwoliłoby edytować także bloga).

Podsumowanie

Zasada Najmniejszych Przywilejów: Dawaj użytkownikom tylko to, czego potrzebują.
Własne Role: Lepsze niż hackowanie roli ‘Redaktor’.
Baza Danych: Role żyją w bazie, nie w kodzie. Zmiany są trwałe.

Opanowanie konkretnych uprawnień to różnica między bezpieczną stroną, a taką, która zostanie zhackowana.

Chcesz dowiedzieć się więcej o profesjonalnym programowaniu WordPress? Przeczytaj kim jest programista WordPress oraz sprawdź cennik usług WordPress.

Role i Uprawnienia WordPress: Kompletny Przewodnik Dewelopera (2026)