Bezpieczeństwo struktury folderów WordPress: jak zablokować dostęp do folderu "wp-includes"

Bezpieczeństwo struktury folderów WordPress najlepiej zapewnić, nie blokując dostępu do całego folderu "wp-includes", lecz ograniczając bezpośrednie uruchamianie plików PHP oraz wyłączając przeglądanie katalogu. Folder wp-includes zawiera niezbędne JavaScripty, pliki CSS oraz statyczne zasoby, które są kluczowe dla działania rdzenia WordPress. Blokowanie całego folderu może skutkować problemami z wyglądem strony, edytorem czy funkcjami wtyczek. Najlepszym rozwiązaniem jest zastosowanie reguł w .htaccess (dla Apache) lub bloków location w konfiguracji Nginx, które zabronią bezpośredniego wywoływania plików PHP, a następnie dokładne przetestowanie strony, sprawdzając odpowiedzi 403/404 i najważniejsze funkcjonalności.

Jednym z najczęstszych błędów w zabezpieczeniach WordPress jest poleganie wyłącznie na silnym haśle czy wtyczkach zabezpieczających. Atakujący często skanują katalogi z plikami rdzenia, stare wtyczki, nieprawidłowe uprawnienia plików oraz otwarte listy katalogów. Folder wp-includes jest jednym z takich celów. W tym poradniku znajdziesz praktyczne wskazówki, jak skutecznie ograniczyć dostęp do wp-includes, które reguły mogą spowodować problemy, przykładowe konfiguracje dla Apache i Nginx, metody testowania oraz checklistę do utrzymania bezpieczeństwa. Aby dodatkowo zwiększyć ochronę WordPress, warto rozważyć Hosting WordPress oraz warstwę ochronną w postaci Certyfikat SSL.

Czym jest folder wp-includes i dlaczego należy go chronić?

Folder wp-includes to jeden z kluczowych katalogów rdzenia WordPress, zawierający podstawowe biblioteki. To tutaj znajdują się elementy systemu szablonów, edytora blokowego, komponenty REST API, przetwarzanie mediów, klasy, funkcje oraz różnorodne pliki JavaScript. Mówiąc obrazowo, wp-includes to „silnik” WordPress, a nie obszar, do którego użytkownik powinien mieć bezpośredni dostęp.

Zwykły użytkownik nie powinien wchodzić na adres typu site.com/wp-includes/. Jednak w kodzie strony mogą pojawiać się odwołania do statycznych zasobów z tego folderu, np. domyślne skrypty WordPress, emoji czy pliki edytora. Dlatego podczas zabezpieczania tego katalogu trzeba precyzyjnie ograniczyć dostęp – zablokować wywoływanie plików PHP bez uszkadzania dostępu do statycznych plików.

To właśnie takie rozgraniczenie jest podstawą profesjonalnego podejścia do bezpieczeństwa struktury folderów WordPress. Automatyczne blokowanie całego folderu może prowadzić do tzw. białej strony, błędów w panelu administratora, niedziałającego edytora blokowego czy problemów z wyglądem strony. Celem jest więc ochronić niezbędne pliki, jednocześnie minimalizując powierzchnię ataku.

Co zyskujemy, blokując dostęp do wp-includes?

Zablokowanie bezpośredniego uruchamiania plików PHP w folderze wp-includes samo w sobie nie powstrzyma wszystkich ataków, ale znacząco zmniejszy powierzchnię ataku. Zwłaszcza na stronach zainfekowanych złośliwym oprogramowaniem hakerzy próbują przesyłać złośliwe pliki PHP lub wywoływać istniejące pliki przez HTTP. Zablokowanie takich wywołań w wp-includes stanowi dodatkową barierę.

Oto główne korzyści takiego rozwiązania:

• Ograniczenie możliwości bezpośredniego wywoływania plików PHP rdzenia WordPress przez URL.
• Pomoc w ukryciu zawartości folderu w przypadku włączonego przeglądania katalogów.
• Zmniejszenie wycieku informacji podczas automatycznych skanów botów.
• Ochrona na poziomie serwera, nawet gdy brak jest wtyczek zabezpieczających.
• Wzmocnienie bezpieczeństwa dzięki współpracy z WAF, SSL, aktualnym PHP i poprawnymi uprawnieniami.

Warto podkreślić, że jest to jedna z warstw ochrony. Jeśli mamy stare wtyczki, słabe hasła czy przejęte konto FTP, sama blokada wp-includes nie wystarczy. Bezpieczeństwo to połączenie infrastruktury hostingu, aplikacji, zarządzania użytkownikami i regularnej konserwacji. Dla solidnego fundamentu warto zapoznać się z Bezpieczny Web Hosting oraz wzmocnić ochronę domeny (Bezpieczeństwo Domeny).

Najczęstsze błędy przy blokowaniu wp-includes

Całkowite zablokowanie folderu

Najczęstszym błędem jest zablokowanie wszystkich żądań HTTP kierowanych do folderu wp-includes kodem 403. Choć na pierwszy rzut oka wydaje się to logiczne, WordPress ładuje z tego folderu statyczne pliki, więc takie podejście może powodować awarie – np. edytor blokowy się nie załaduje, niektóre skrypty JavaScript nie będą dostępne, a frontend może mieć drobne, ale istotne błędy wizualne.

Wprowadzanie reguł bez testów

Błąd w .htaccess lub konfiguracji Nginx, nawet pojedynczy znak, może wywołać błąd 500 Internal Server Error. Na stronach o dużym ruchu wdrażanie zmian bez testów jest ryzykowne. Najpierw należy wykonać kopię zapasową pliku konfiguracyjnego, przetestować zmiany na środowisku stagingowym, a dopiero potem wdrożyć na produkcję. Jeśli korzystasz z Hostragons i masz dostęp do staging lub backupów, warto o tym pamiętać (Kopia zapasowa hostingu WWW).

Pełne poleganie na wtyczkach bezpieczeństwa

Wtyczki zabezpieczające są pomocne, ale reguły na poziomie serwera blokują żądania zanim trafią do PHP, co zmniejsza zużycie zasobów. Dlatego nawet jeśli korzystasz z wtyczek, nie powinieneś rezygnować z podstawowych reguł w .htaccess czy konfiguracji Nginx.

Checklista przed wdrożeniem blokady wp-includes

Przed ograniczeniem dostępu do wp-includes warto przeprowadzić krótkie przygotowania, które zminimalizują ryzyko awarii. Oto rekomendowana lista kroków, zwłaszcza dla stron produkcyjnych:

• Zrób kopię zapasową aktualnego .htaccess lub konfiguracji Nginx.
• Zaktualizuj rdzeń WordPress, motywy i wtyczki do najnowszych wersji.
• Sprawdź, czy używasz wspieranego i bezpiecznego PHP.
• Zweryfikuj uprawnienia plików: katalogi powinny mieć 755, pliki 644.
• Upewnij się, że pliki krytyczne, takie jak wp-config.php i .htaccess, nie mają nadmiernych uprawnień do zapisu.
• Jeśli korzystasz z cache, CDN lub wtyczek bezpieczeństwa, zaplanuj wyczyszczenie pamięci podręcznej po zmianach.
• Przygotuj listę najważniejszych elementów do przetestowania: panel administracyjny, strona główna, wpisy, formularze kontaktowe, strony płatności itp.

Przygotowanie zajmie około 10-15 minut, ale pozwoli uniknąć godzin przestojów spowodowanych błędną konfiguracją. W przypadku stron firmowych zmiany najlepiej wprowadzać w godzinach o najmniejszym ruchu.

Blokada PHP w wp-includes za pomocą .htaccess na serwerze Apache

Na współdzielonych hostingach Apache najpopularniejszym sposobem ochrony jest modyfikacja pliku .htaccess. Dodając odpowiednie reguły w pliku .htaccess w katalogu głównym WordPress, możemy zablokować wywołania PHP w folderze wp-includes. Przed rozpoczęciem pobierz kopię .htaccess na komputer lub wykonaj backup przez panel hostingu.

Zalecana reguła .htaccess

Poniższy kod blokuje bezpośredni dostęp do plików PHP w wp-includes, jednocześnie pozwalając na ładowanie statycznych zasobów:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

Reguła ta mówi: jeśli URL zaczyna się od wp-includes i kończy na .php, zwróć błąd 403 Forbidden. Dostęp do plików .js, .css, .png, .svg pozostaje nienaruszony, co zapewnia prawidłowe działanie strony i panelu administracyjnego.

Wyłączenie przeglądania katalogów

Ważną praktyką jest wyłączenie listowania zawartości katalogów, aby użytkownicy nie mogli zobaczyć plików, jeśli nie ma tam pliku index. W pliku .htaccess wystarczy dodać:

Options -Indexes

Ten zapis zapobiega wyświetlaniu list plików w folderach bez pliku indeksowego. Choć na większości nowoczesnych hostingów jest to domyślnie wyłączone, warto to zweryfikować.

Testowanie po wdrożeniu

Po wprowadzeniu zmian wykonaj następujące testy:

• Otwórz adres siteadres.com/wp-includes/ – nie powinno wyświetlać się listowanie plików.
• Spróbuj bezpośrednio wywołać znany plik PHP z wp-includes, np. siteadres.com/wp-includes/pliki.php – powinien zwrócić błąd 403 lub 404.
• Sprawdź, czy strona główna, wpisy i panel administracyjny działają poprawnie.
• Przeanalizuj konsolę i zakładkę sieci w narzędziach deweloperskich przeglądarki pod kątem błędów 403/404.
• Wyczyść cache wtyczek i CDN, jeśli są używane.

Jeśli wszystko działa poprawnie, regułę można pozostawić w środowisku produkcyjnym. W przypadku błędu 500 najlepiej cofnąć zmiany, przywracając kopię zapasową .htaccess.

Blokada PHP w wp-includes na serwerze Nginx

Na serwerach Nginx .htaccess nie działa, dlatego konieczne jest dodanie reguł bezpośrednio do pliku konfiguracyjnego serwera (zazwyczaj w bloku server). Do edycji potrzebny jest dostęp SSH oraz uprawnienia do modyfikacji konfiguracji. Jeśli nie masz pewności, skontaktuj się z pomocą techniczną hostingu.

Zalecana reguła location

Podstawowa reguła blokująca PHP w wp-includes może wyglądać tak:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

Zablokuje to wszystkie żądania do plików PHP w folderze wp-includes. Po wprowadzeniu zmian należy przetestować konfigurację poleceniem:

nginx -t

Jeśli test zakończy się powodzeniem, przeładuj Nginx poleceniem:

systemctl reload nginx

Reload jest bezpieczniejszy niż restart, ponieważ nie przerywa aktualnych połączeń. Na krytycznych serwisach warto wdrożenie przeprowadzać w godzinach o niskim ruchu.

Wskazówki dla użytkowników Nginx

• Upewnij się, że reguła jest dodana do właściwego bloku server, zwłaszcza gdy na serwerze działa wiele stron.
• Jeśli korzystasz z CDN lub reverse proxy, testuj po wyczyszczeniu cache.
• Zweryfikuj, że konfiguracja PHP-FPM obsługuje odpowiednio tylko wymagane pliki.
• Monitoruj logi serwera (access.log i error.log) – szybko wykryjesz błędne reguły.

W Nginx niewłaściwa kolejność reguł location może powodować nieoczekiwane efekty, dlatego należy zwrócić uwagę na kompatybilność z regułami WordPressa i konfiguracją PHP.

Porównanie metod blokowania wp-includes

Poniższa tabela przedstawia najpopularniejsze metody ograniczania dostępu do wp-includes:

Najlepsze efekty osiąga się, stosując te metody łącznie. Na przykład na hostingu Apache warto połączyć regułę .htaccess, odpowiednie uprawnienia, aktualną wersję WordPress, SSL oraz regularne kopie zapasowe. W środowiskach korporacyjnych ważne są także zapory i izolacja (Hosting dla firm).

Uprawnienia plików i właściciel

Blokada wp-includes jest nieskuteczna, jeśli pliki mają niewłaściwe uprawnienia. Standardowo foldery powinny mieć 755, a pliki 644, co pozwala serwerowi czytać, ale nie nadmiernie zapisywać plików. W niektórych hostingach mogą obowiązywać inne zasady ze względu na konfigurację użytkowników i grup.

Szczególnie niebezpieczne jest nadanie 777 (pełny dostęp dla wszystkich), co ułatwia włamania i upload złośliwych plików. Nawet w folderach takich jak wp-content/uploads, które muszą być zapisywalne, warto wyłączyć możliwość uruchamiania plików PHP. Folder wp-includes powinien być zapisywalny tylko podczas aktualizacji WordPress i wyłącznie przez uprawnionego użytkownika.

Podczas audytu bezpieczeństwa warto sprawdzić:

• Folder wp-includes: zazwyczaj 755
• Pliki PHP w wp-includes: zazwyczaj 644
• Plik wp-config.php: najlepiej 600 lub bardziej restrykcyjne w zależności od hostingu
• Plik .htaccess: zazwyczaj 644, bez nadmiarowych uprawnień do zapisu

Uprawnienia mogą różnić się między serwerami, więc po zmianach należy monitorować logi i wykonywać testy WordPress Health Check.

Czy wtyczki zabezpieczające wykonują tę pracę?

Popularne wtyczki jak Wordfence czy iThemes Security automatycznie proponują pewne reguły hardeningu. Oferują ochronę przed brute force, monitorowanie zmian w plikach, skanowanie złośliwego kodu czy zabezpieczenie logowania. Jednak w kwestii blokady wp-includes warto zweryfikować, co dokładnie robi wtyczka.

Niektóre wtyczki automatycznie dodają reguły do .htaccess, inne działają tylko na poziomie aplikacji, co oznacza, że żądanie dochodzi do WordPress, zanim zostanie zablokowane. Dlatego profesjonalne podejście to połączenie zabezpieczeń na poziomie serwera i aplikacji.

Jeśli korzystasz z wtyczek zabezpieczających, zwróć uwagę na:

• Czy wtyczka dodaje reguły do .htaccess lub konfiguracji Nginx.
• Unikanie konfliktów między różnymi regułami i wtyczkami.
• Sprawdzanie, czy ustawienia nie zmieniają się po aktualizacji wtyczki.
• Monitorowanie wpływu na wydajność, np. poprzez analizę cache i zużycia zasobów.

Stosowanie wielu wtyczek bezpieczeństwa jednocześnie może prowadzić do konfliktów, spowolnień lub niezamierzonych blokad.

Jak przetestować ochronę wp-includes: praktyczny scenariusz

Sam fakt, że strona się ładuje, nie gwarantuje sukcesu. Poniższy 7-punktowy test można zastosować na małych stronach firmowych i dużych sklepach internetowych:

• 1. Otwórz stronę główną w trybie incognito i sprawdź, czy nie ma błędów wizualnych.
• 2. Przejdź do wpisu na blogu, strony kategorii i strony wyników wyszukiwania.
• 3. Zaloguj się do panelu administracyjnego i otwórz edytor blokowy oraz bibliotekę mediów.
• 4. Sprawdź konsolę przeglądarki pod kątem błędów JavaScript.
• 5. W zakładce Network upewnij się, że statyczne pliki z wp-includes nie są blokowane.
• 6. Spróbuj bezpośrednio wywołać plik PHP z wp-includes i oczekuj błędu 403 lub 404.
• 7. Przejrzyj logi błędów serwera pod kątem nowych lub powtarzających się problemów.

Test zajmie około 5 minut i szybko wyłapie problemy z konfiguracją. W sklepach WooCommerce warto dodatkowo przetestować koszyk, płatności i konto użytkownika, gdyż nawet drobne błędy JavaScript mogą obniżyć konwersję.

Dodatkowe zabezpieczenia struktury WordPress

Ochrona wp-includes to dobry początek, ale bezpieczeństwo WordPress wymaga całościowego podejścia. Oto kilka dodatkowych kroków, które zmniejszą ryzyko ataków:

• Nie ukrywaj wersji WordPress – zamiast tego regularnie aktualizuj rdzeń.
• Usuń nieużywane motywy i wtyczki.
• Zmień domyślną nazwę administratora na trudną do odgadnięcia.
• Włącz uwierzytelnianie dwuskładnikowe (2FA).
• Ogranicz lub wyłącz dostęp do XML-RPC, jeśli nie jest potrzebny.
• Na stronie logowania zastosuj limit prób lub dodatkowe zabezpieczenia.
• Wdroż automatyczne codzienne kopie zapasowe i regularnie je testuj.
• Korzystaj z HTTPS na całej stronie – bez SSL dane logowania są zagrożone.

SSL nie zablokuje wp-includes, ale zabezpiecza sesje użytkowników, przesył danych formularzy i panel admina. Dlatego jest to podstawowa warstwa zabezpieczeń. Warto zapoznać się z Kup certyfikat SSL oraz Instalacja darmowego SSL.

Kiedy warto skorzystać z profesjonalnej pomocy?

Dodanie reguły w .htaccess na prostym hostingu Apache jest zwykle intuicyjne. Jednak w przypadku zaawansowanych konfiguracji Nginx, multisite, sklepów WooCommerce, stron o dużym ruchu lub portali korporacyjnych, warto sięgnąć po wsparcie specjalistów. Zabezpieczenia muszą być nie tylko technicznie poprawne, ale i bezpieczne dla ciągłości działania serwisu.

Profesjonalna pomoc jest wskazana, gdy:

• Na serwerze działa wiele instalacji WordPress.
• Kombinujesz Nginx, Varnish, CDN i WAF.
• Po zmianach wzrosła liczba błędów 403, 404 lub 500.
• Strona była wcześniej zainfekowana malware.
• Obsługujesz płatności, dane osobowe lub systemy członkowskie.

Bezpieczna infrastruktura hostingu, izolacja środowisk, regularne backupy i wsparcie eksperckie to kluczowe, choć niewidoczne elementy bezpieczeństwa. Wybierając hosting, zwróć uwagę nie tylko na miejsce na dysku, ale też backupy, zaporę, wsparcie dla PHP, zarządzanie SSL i jakość pomocy technicznej. Materiały Hostragons Pakiety Hostingu i Przenoszenie strony WordPress mogą być pomocne przy wyborze.

Podsumowanie

Bezpieczne blokowanie dostępu do folderu wp-includes polega na uniemożliwieniu bezpośredniego wywoływania plików PHP oraz wyłączeniu listowania katalogu, a nie na blokowaniu całego folderu. Można to zrobić szybko i skutecznie za pomocą reguł .htaccess na Apache lub location w Nginx. Zawsze wykonuj kopię zapasową, a po zmianach dokładnie testuj panel i frontend.

Podsumowując: nie blokuj statycznych plików, ogranicz dostęp do PHP, wyłącz listowanie katalogów, kontroluj uprawnienia i regularnie aktualizuj WordPress. Dla bezpieczniejszego i bardziej stabilnego środowiska hostingowego warto rozważyć rozwiązania Hostragons, łączące hosting, domenę i SSL oraz wsparcie specjalistów.

Najczęściej zadawane pytania

Czy całkowite zablokowanie folderu wp-includes jest bezpieczne?

Zwykle nie jest to rekomendowane. W folderze znajdują się potrzebne pliki JavaScript, CSS i inne zasoby statyczne. Całkowita blokada może zaburzyć wygląd strony lub działanie panelu administracyjnego. Bezpieczniejszym rozwiązaniem jest blokada tylko plików PHP.

Co zrobić, gdy po dodaniu reguły .htaccess pojawia się błąd 500?

Najpierw usuń ostatnio dodane reguły lub przywróć kopię zapasową pliku .htaccess. Następnie sprawdź składnię reguł. Jeśli problem się utrzymuje, przejrzyj logi serwera i skontaktuj się z pomocą techniczną hostingu.

Czy na serwerze Nginx działa .htaccess?

Nie. .htaccess działa tylko na serwerach Apache i LiteSpeed. W Nginx podobne ograniczenia wprowadza się w konfiguracji serwera, w bloku server przez reguły location. Po zmianie konfiguracji należy przetestować ją poleceniem nginx -t.

Czy ta metoda całkowicie zabezpiecza moją stronę WordPress?

Nie. Blokada dostępu do PHP w wp-includes to ważna warstwa bezpieczeństwa, ale konieczne jest stosowanie także aktualizacji, silnych haseł, 2FA, SSL, backupów, firewalli i prawidłowych uprawnień.

Czy jeśli używam wtyczki zabezpieczającej, muszę dodatkowo dodawać reguły blokujące wp-includes?

To zależy od wtyczki. Niektóre automatycznie dodają reguły do .htaccess, inne działają tylko na poziomie aplikacji. Zazwyczaj najlepsze efekty daje połączenie zabezpieczeń serwera i wtyczki, aby uniknąć konfliktów i zwiększyć ochronę.