DISALLOW_FILE_EDIT: wyłączenie edytora plików WordPress

Wystarczy jedna linia w wp-config.php: define( 'DISALLOW_FILE_EDIT', true );. Usuwa ona z panelu administracyjnego Edytor plików motywów i Edytor plików wtyczek. Zajmuje to dwie minuty i nie wpływa na aktualizacje. Likwiduje też najkrótszą drogę od skradzionego hasła administratora do kodu uruchamianego na Państwa serwerze.

Ten artykuł wyjaśnia, dlaczego DISALLOW_FILE_EDIT ma znaczenie, jak bezpiecznie go ustawić i przed czym nie chroni. Pokazuje też, kiedy warto sięgnąć po mocniejszą stałą DISALLOW_FILE_MODS, mimo że wymaga więcej pracy.

Dlaczego DISALLOW_FILE_EDIT ma znaczenie: od logowania administratora do uruchomionego kodu

WordPress ma dwa wbudowane edytory kodu. Edytor plików motywów znajduje się w menu Wygląd (motywy klasyczne) albo Narzędzia (motywy blokowe). Edytor plików wtyczek jest w menu Wtyczki w przypadku motywów klasycznych, a przy motywach blokowych również w Narzędzia. Oba pozwalają administratorom (w sieci multisite superadministratorom) zmieniać pliki PHP w przeglądarce i je zapisywać, a serwer wykona ten kod przy następnym wczytaniu strony.

Dostęp do konta administratora jest więc w praktyce dostępem do powłoki. Osoba, która zdobyła hasło administratora przez phishing, dzięki jego ponownemu użyciu albo atakiem brute force, może otworzyć functions.php i wkleić backdoora. Może też dodać ukryte przekierowanie dla osób wchodzących z wyszukiwarki albo wstrzyknąć do szablonu koszyka skimmer kart płatniczych. Nie potrzebuje do tego FTP ani dostępu do hostingu, wystarczy samo logowanie.

Większość serwisów produkcyjnych nigdy nie potrzebuje edycji kodu w przeglądarce. Programiści pracują w edytorze kodu, na środowisku testowym albo przez system kontroli wersji. Edycja działającego kodu PHP w polu tekstowym nie ma cofania ani przeglądu zmian, a jeden błąd składni może wyłączyć całą witrynę. W firmowym serwisie edytor dodaje ryzyko i prawie nic poza nim.

Ochrona samego logowania to osobne zadanie. Opisujemy je w poradniku o uwierzytelnianiu dwuskładnikowym dla administratorów WordPressa. DISALLOW_FILE_EDIT ogranicza to, co można zrobić przy skradzionym loginie.

Jak dodać DISALLOW_FILE_EDIT do wp-config.php

1. Pobierzcie kopię wp-config.php i zachowajcie ją jako kopię zapasową. U wielu dostawców hostingu plik leży w katalogu głównym WordPressa. W niektórych konfiguracjach znajduje się piętro wyżej.
2. Otwórzcie plik przez SFTP albo w menedżerze plików hostingu. Nie używajcie do tego wtyczki WordPressa.
3. Wyszukajcie w pliku DISALLOW_FILE_EDIT. Jeśli stała jest już zdefiniowana, zmieńcie tę linię zamiast dodawać drugą. Podwójna definicja stałej wywołuje ostrzeżenie PHP.
4. Dodajcie linię nad komentarzem zaczynającym się od /* That's all, stop editing!. Musi znaleźć się przed załadowaniem wp-settings.php.
5. Zapiszcie plik, wyślijcie go na serwer i odświeżcie panel.

/* Disable the Theme and Plugin File Editors in the dashboard */
define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */

Następnie sprawdźcie efekt. Pozycje menu Edytor plików motywów i Edytor plików wtyczek powinny zniknąć. Jeśli otworzycie bezpośrednio adres /wp-admin/theme-editor.php, zamiast edytora zobaczycie komunikat o braku uprawnień.

Tej stałej nie da się włączyć z powrotem z poziomu panelu i właśnie o to chodzi. Kto chce przywrócić edytor, potrzebuje dostępu do plików na serwerze, a nie tylko hasła administratora. Ustawienie obowiązuje dla całej instalacji, a w sieci multisite obejmuje każdą witrynę. Oficjalna dokumentacja wp-config.php wymienia ją razem z pozostałymi stałymi konfiguracyjnymi.

Jeśli nie macie dostępu do SFTP ani menedżera plików, wtyczka Security Audit & Compliance od secaudit.eu ma opcjonalny przełącznik, który wyłącza edytory plików w panelu.

Przed czym wyłączenie edytora plików nie chroni

DISALLOW_FILE_EDIT usuwa najłatwiejszą drogę. Nie sprawia jednak, że konto administratora staje się niegroźne. Administrator albo atakujący, który się nim posługuje, nadal może:

• wgrać archiwum zip z wtyczką lub motywem zawierające złośliwy kod, w Wtyczki → Dodaj nową albo Wygląd → Motywy
• tworzyć nowe konta administratorów, zmieniać adres e-mail administratora lub resetować hasła innych użytkowników
• zmieniać ustawienia, takie jak adres witryny, rejestracja użytkowników czy domyślna rola
• wyeksportować dane użytkowników i zamówień

Atakujący z dostępem do FTP, SSH, panelu hostingu lub bazy danych w ogóle omijają WordPressa i żadna stała w wp-config.php ich nie zatrzyma. Stała nie pomaga też przy podatnych wtyczkach, które można wykorzystać bez żadnego logowania. To osobny problem z własnymi rozwiązaniami, opisany w naszym poradniku o podatnych wtyczkach WordPressa.

DISALLOW_FILE_EDIT należy traktować jako jedną z warstw ochrony. Jest tania i warto ją mieć, ale nie naprawia słabego logowania ani niezaktualizowanej wtyczki.

Menedżery plików i wtyczki ze snippetami: ten sam edytor pod inną nazwą

Kilka rodzajów wtyczek przywraca to samo ryzyko, a DISALLOW_FILE_EDIT ich nie obejmuje:

• menedżery plików, które pozwalają przeglądać, edytować i wgrywać pliki z panelu
• menedżery snippetów, które przechowują kod PHP i wykonują go przy każdym żądaniu
• pola „wstaw kod do nagłówka/stopki”, które przyjmują skrypty lub PHP
• opcje motywu albo page buildera z polem „własny kod”

Jeśli któraś z nich jest aktywna, atakujący z loginem administratora nadal ma edytor kodu.

Zacznijcie od inwentaryzacji. Przejrzyjcie Wtyczki → Zainstalowane wtyczki i opcje motywu, a następnie zanotujcie wszystko, co potrafi edytować pliki albo uruchamiać własny kod. Potem zajmijcie się każdym rodzajem osobno:

• Menedżery plików: usuńcie je, gdy tylko skończy się jednorazowe zadanie. Sama dezaktywacja nie wystarczy, bo kod zostaje na serwerze i sam może zawierać podatności.
• Snippety, których naprawdę potrzebujecie: przenieście je do niewielkiej własnej wtyczki albo motywu potomnego i trzymajcie w systemie kontroli wersji. Zmiany przechodzą wtedy przez zwykłe wdrożenie, a nie przez przeglądarkę.
• Menedżery snippetów, które zostają: sprawdźcie, które role mogą tworzyć i edytować snippety, i ogranicz to do jak najmniejszej liczby osób.

DISALLOW_FILE_MODS: mocniejsza blokada i realne koszty

define( 'DISALLOW_FILE_MODS', true ); idzie dalej. Blokuje instalowanie, aktualizowanie i usuwanie wtyczek oraz motywów z panelu. Wyłącza też automatyczne aktualizacje w tle. Zamyka w ten sposób drogę przez wgranie zipa, którą DISALLOW_FILE_EDIT zostawia otwartą.

Cena jest taka, że nic nie aktualizuje się samo. Jeśli nikt nie robi aktualizacji w inny sposób, witryna z czasem zostaje w tyle z poprawkami bezpieczeństwa. Z panelu znikają też zwykłe powiadomienia o aktualizacjach. Na wyłączone aktualizacje w tle wskazuje tylko Stan witryny (Site Health), więc łatwo przeoczyć tę lukę.

Ścieżka aktualizacji przed włączeniem DISALLOW_FILE_MODS

Wybierzcie jedno z poniższych podejść i wprowadźcie je do rutyny:

• WP-CLI na serwerze. Aktualizacje uruchamiane z wiersza poleceń, ręcznie albo jako zadanie cykliczne:

wp core update
wp plugin update --all
wp theme update --all

• Wdrożenia przez Git lub Composera. Wersje wtyczek i motywów są zapisane w repozytorium, a potok (pipeline) buduje i wdraża serwis. Aktualizacje stają się commitami, które można przejrzeć i wycofać.
• Narzędzia aktualizacji u dostawcy hostingu zarządzanego. Niektórzy dostawcy aktualizują serwis za Państwa, często po wykonaniu kopii zapasowej lub kontroli wizualnej. Trzeba dokładnie sprawdzić, co jest objęte usługą i czy obejmuje wtyczki premium.

Wybraną metodę przetestujcie na kopii testowej, na której DISALLOW_FILE_MODS jest już włączone. To, co zadziała, zależy od konfiguracji serwera, więc potwierdźcie to przed zmianą na produkcji.

Zaplanujcie aktualizacje w cronie albo przez wyzwalacz w potoku i sprawdźcie, czy zadanie faktycznie się uruchamia. Zadanie, które cicho zawodzi, jest równie dobre jak jego brak. Prowadźcie zapis tego, co i kiedy zaktualizowano. Taki dziennik jest przydatnym dowodem na „odpowiednie środki techniczne i organizacyjne” w rozumieniu art. 32 RODO.

Liczy się tempo. Patchstack, dostawca rozwiązań bezpieczeństwa, podaje w raporcie State of WordPress Security in 2026, że ważona mediana czasu do masowej eksploatacji wyniosła 5 godzin w przypadku intensywnie wykorzystywanych podatności. Miesięczna runda ręcznych aktualizacji za tym nie nadąży.

Sprawdzanie, czy blokada nadal działa

Stałe łatwo gubią się przy migracjach, zmianie hostingu i „tymczasowym” debugowaniu. Warto je co jakiś czas sprawdzić:

grep -n DISALLOW_FILE wp-config.php
wp config get DISALLOW_FILE_EDIT

Pierwsze polecenie pokazuje każdą pasującą linię wraz z jej numerem. Drugie wyświetla wartość, którą WP-CLI odczytuje z konfiguracji. Uruchamiajcie oba po każdej przeprowadzce na nowy serwer lub do nowego dostawcy. Obserwujcie też nieoczekiwane zmiany w plikach PHP motywu i wtyczek. Przy działającej blokadzie taka zmiana oznacza, że ktoś dostał się inną drogą.

Jeśli okaże się, że edytor został już użyty przeciwko Państwu, to nie jest już utwardzanie, tylko reagowanie na incydent. Zanim zmienicie cokolwiek innego, przeczytajcie nasze poradniki o wykrywaniu web shelli i usuwaniu malware z WordPressa.

Wtyczka audytowa od secaudit.eu sprawdza ustawienia utwardzania i konfiguracji, w tym edytor plików. Śledzi też integralność plików względem wzorca, dzięki czemu zmiany w plikach motywu i wtyczek pojawiają się w raporcie → secaudit.eu

FAQ

Czy DISALLOW_FILE_EDIT zepsuje witrynę lub aktualizacje?

Nie. Usuwa tylko dwa edytory w panelu. Aktualizacje wtyczek, motywów i rdzenia, także automatyczne, nadal działają. Sposób aktualizacji zmienia dopiero DISALLOW_FILE_MODS.

Czy mogę tymczasowo przywrócić edytor?

Tak. Wystarczy ustawić stałą na false albo zakomentować linię, a potem ją przywrócić. Lepiej jednak edytować plik przez SFTP lub na środowisku testowym, żeby edytor w ogóle nie musiał wracać.

Czy WordPress ma to ustawienie w panelu?

Nie. Rdzeń nie ma takiej opcji w panelu; to stała ustawiana w wp-config.php. Jeśli nie można edytować tego pliku, trzeba użyć wtyczki z przełącznikiem wyłączającym edytory plików.