Przy utrzymaniu stron moich klientów regularnie widzę w logach serwera setki automatycznych prób logowania i zapytań do xmlrpc.php. Część z nich odcinam, zanim w ogóle dotrą do WordPressa – bez instalowania kolejnej wtyczki, tylko w plikach .htaccess i wp-config.php.
W tym poradniku pokażę Ci, jak zablokować XML-RPC, dodać drugą warstwę logowania przed wp-login.php, wyłączyć listowanie katalogów i edycję plików z kokpitu. Od razu zaznaczam: to hardening, czyli dodatkowe utwardzenie strony. Nie zastępuje aktualizacji, kopii zapasowych, kontroli kont użytkowników ani – przy większych serwisach – zapory aplikacyjnej (WAF). Przykłady dotyczą serwerów Apache i zgodnych z nim, np. LiteSpeed.
Dlaczego warto wzmacniać zabezpieczenia WordPressa bez wtyczek
Reguły w pliku .htaccess działają na poziomie serwera, czyli zanim żądanie trafi do PHP i WordPressa. Dzięki temu niechciany ruch odrzucam wcześniej i mniejszym kosztem dla serwera.
Nie twierdzę, że wtyczki bezpieczeństwa są zbędne. W wielu projektach sam z nich korzystam, bo dają to, czego .htaccess nie zapewni: monitoring, logi zdarzeń, skanowanie plików i powiadomienia. Ten poradnik pokazuje kilka prostych kroków, które wdrażam jako uzupełnienie – szczególnie na małych stronach firmowych na hostingu współdzielonym.
Ważne: opisane tu zabezpieczenia ograniczają wybrane drogi ataku, ale nie chronią przed lukami w samym WordPressie, wtyczkach czy motywach. Aktualizacje, silne hasła i kopie zapasowe nadal są podstawą.
Kopia zapasowa pliku .htaccess – obowiązkowy pierwszy krok
Zanim zmienisz plik .htaccess, pobierz jego kopię na komputer. Jedna literówka albo dyrektywa nieobsługiwana przez hosting może wywołać błąd 500 Internal Server Error i wyłączyć całą stronę.
Plik znajdziesz zwykle w katalogu głównym WordPressa, najczęściej w folderze public_html, www lub htdocs. Pliki zaczynające się od kropki bywają ukryte – w menedżerze plików lub kliencie FTP/SFTP włącz pokazywanie plików ukrytych.
Kopię nazwij np. htaccess-backup-pazdziernik-2026.txt, żeby nie pomylić jej z aktywnym plikiem. Jeśli po zmianach strona przestanie działać, po prostu przywróć poprzednią wersję. Warto też sprawdzić, czy Twój hosting ma historię plików lub automatyczne kopie – w awarii oszczędza to sporo nerwów.
Jak zablokować XML-RPC w WordPressie przez .htaccess
XML-RPC to mechanizm WordPressa do zdalnej komunikacji ze stroną. Większość stron firmowych, które prowadzę, w ogóle go nie potrzebuje, a jest on częstym celem botów. Zablokowanie pliku xmlrpc.php całkowicie odcina ten punkt wejścia.
Uwaga: jeśli korzystasz z Jetpacka, aplikacji mobilnej WordPress lub innej integracji opartej na XML-RPC, najpierw sprawdź jej wymagania – po blokadzie może przestać działać.
Regułę umieść poza blokiem # BEGIN WordPress – # END WordPress. WordPress nadpisuje zawartość tego bloku, np. przy zmianie ustawień bezpośrednich odnośników.
Apache 2.4 i nowsze
Na Apache 2.4 używaj składni opartej na Require:
# Blokada dostępu do XML-RPC
<Files "xmlrpc.php">
Require all denied
</Files>Starszy Apache 2.2
Jeśli Twój hosting nadal działa na Apache 2.2, spotkasz starszą składnię:
# Blokada dostępu do XML-RPC – Apache 2.2
<Files "xmlrpc.php">
Order Allow,Deny
Deny from all
</Files>Na nowych serwerach zawsze wybieram Require. Dyrektywy Order, Allow i Deny działają w Apache 2.4 tylko dzięki modułowi zgodności wstecznej.
Jak sprawdzić, czy blokada działa?
Po zapisaniu zmian otwórz adres twojastrona.pl/xmlrpc.php. Prawidłowy wynik to 403 Forbidden. Jeśli widzisz błąd 500, cofnij zmianę i sprawdź, czy hosting obsługuje tę dyrektywę.
Pamiętaj, że blokada xmlrpc.php nie zabezpiecza samego logowania do WordPressa – wyłącza tylko ten jeden punkt dostępu.
Zabezpieczenie wp-login.php przez HTTP Basic Auth
Jednym z moich ulubionych sposobów na ograniczenie botów jest dodatkowe okno logowania przed formularzem WordPressa. Apache prosi wtedy o osobny login i hasło zapisane w pliku .htpasswd, zanim w ogóle pokaże wp-login.php.
Ta metoda chroni sam plik wp-login.php – nie cały katalog /wp-admin/ i nie całą instalację. Do działania potrzebne są odpowiednie ustawienia AllowOverride i aktywne moduły uwierzytelniania po stronie hostingu.
Zanim wdrożysz Basic Auth – sprawdź skutki uboczne:
- Wpisy chronione hasłem korzystają z adresu
wp-login.php?action=postpass. Odwiedzający zobaczą dodatkowe okno logowania i nie odczytają treści. - Wylogowanie i reset hasła również przechodzą przez wp-login.php, więc dodatkowe okno pojawi się także tam.
- Klienci WooCommerce logujący się na stronie „Moje konto” zwykle korzystają z osobnego formularza i nie są objęci blokadą – ale przetestuj to na swojej konfiguracji.
- OpenLiteSpeed nie obsługuje wszystkich dyrektyw uwierzytelniania z .htaccess. Jeśli Twój hosting go używa, skonfiguruj ochronę w panelu serwera.
Krok 1 – wygenerowanie pliku .htpasswd
Plik .htpasswd przechowuje nazwę użytkownika i zahaszowane hasło. Najbezpieczniej wygenerować go narzędziem htpasswd bezpośrednio na serwerze. Jeśli masz dostęp do SSH, użyj:
htpasswd -B -c /home/twojanazwa/.htpasswd-kamproweb kampro_adminParametr -B włącza algorytm bcrypt, który Apache 2.4 obsługuje w plikach .htpasswd. Uwaga: przełącznik -c tworzy plik od nowa – przy dodawaniu kolejnego użytkownika go pomiń, bo nadpiszesz istniejące wpisy.
Jeśli Twój hosting nie ma generatora ani dostępu do htpasswd, awaryjnie możesz użyć narzędzia online: generator .htpasswd online.
Generator online – na co uważać: to zewnętrzne narzędzie, które według własnej dokumentacji tworzy hashe w oparciu o MD5. Traktuj je jako rozwiązanie awaryjne. Nigdy nie wpisuj tam hasła, którego używasz do WordPressa, poczty czy innych usług – utwórz osobne, silne hasło tylko do Basic Auth.
- Użyj
htpasswd -Bna serwerze albo narzędzia z panelu hostingu. - Jeśli hosting nie ma takiego narzędzia, skorzystaj awaryjnie z generatora online.
- Utwórz osobny login, np. kampro_admin.
- Ustaw silne, unikalne hasło, którego nie używasz nigdzie indziej.
- Skopiuj wygenerowaną linię w formacie login:hash.
- Zapisz ją w pliku, np. .htpasswd-kamproweb.
Krok 2 – umieszczenie pliku .htpasswd poza publicznym katalogiem
Plik .htpasswd nie może być dostępny z przeglądarki – zaleca to również dokumentacja Apache. Jeśli Twoja strona znajduje się w katalogu:
/home/twojanazwa/public_html/plik możesz umieścić np. tutaj:
/home/twojanazwa/.htpasswd-kamprowebNie chodzi o zasadę „zawsze piętro wyżej”, tylko o to, żeby plik leżał poza publiczną przestrzenią WWW. Dokładna lokalizacja zależy od hostingu.
Krok 3 – dodanie Basic Auth do wp-login.php
Otwórz główny plik .htaccess i dodaj regułę poza blokiem # BEGIN WordPress – # END WordPress. W AuthUserFile wpisz rzeczywistą ścieżkę do swojego pliku.
# Dodatkowa ochrona wp-login.php
<Files "wp-login.php">
AuthType Basic
AuthName "Strefa chroniona"
AuthBasicProvider file
AuthUserFile /home/twojanazwa/.htpasswd-kamproweb
Require valid-user
</Files>Następnie otwórz twojastrona.pl/wp-login.php. Przeglądarka powinna pokazać dodatkowe okno logowania, a dopiero po nim standardowy formularz WordPressa.
Basic Auth działa bezpiecznie tylko z HTTPS
HTTP Basic Authentication nie szyfruje loginu i hasła. Bez HTTPS dane mogą zostać przechwycone w trakcie przesyłania. Jeśli Twoja strona nie ma jeszcze certyfikatu SSL/TLS, zacznij od niego – większość hostingów oferuje bezpłatny certyfikat Let’s Encrypt.
Jak zezwolić konkretnemu IP na pominięcie Basic Auth
Jeśli masz stały publiczny adres IP, możesz ustawić Apache tak, żeby z tego adresu nie trzeba było podawać dodatkowego hasła. Wszyscy pozostali nadal przejdą przez Basic Auth. Zamiast samego Require valid-user użyj bloku RequireAny:
# Ochrona wp-login.php z wyjątkiem wskazanego adresu IP
<Files "wp-login.php">
AuthType Basic
AuthName "Strefa chroniona"
AuthBasicProvider file
AuthUserFile /home/twojanazwa/.htpasswd-kamproweb
<RequireAny>
# Zamień 123.45.67.89 na swój stały publiczny adres IP
Require ip 123.45.67.89
Require valid-user
</RequireAny>
</Files>Jak to działa:
- adres 123.45.67.89 wchodzi bez dodatkowego hasła;
- pozostali muszą podać login i hasło z pliku .htpasswd;
- jeśli Twój adres IP się zmieni, wyjątek przestanie działać;
- przy VPN, proxy lub CDN sprawdź, jaki adres IP serwer faktycznie widzi.
Uwaga na adres IP: ta reguła tworzy wyjątek od zabezpieczenia, więc wpisz wyłącznie zaufany adres, który rzeczywiście należy do Ciebie. Jeśli Twój dostawca internetu przydziela zmienne IP, nie stosuj tego wyjątku.
Możesz też dopuścić kilka adresów:
<RequireAny>
Require ip 123.45.67.89
Require ip 98.76.54.32
Require valid-user
</RequireAny>Apache obsługuje również adresy IPv6 i zakresy sieci – używaj ich tylko wtedy, gdy dokładnie wiesz, jaki zakres dopuszczasz.
Bonusowe zabezpieczenia WordPressa bez wtyczek
Poniższe ustawienia nie tworzą kompletnego systemu bezpieczeństwa, ale ograniczają ujawnianie zbędnych informacji i skutki ewentualnego przejęcia konta.
Blokada podglądu katalogów – Options -Indexes
Gdy serwer ma włączone listowanie katalogów, każdy może zobaczyć listę plików w folderze bez pliku indeksowego. Samo w sobie nie jest to luka, ale podaje atakującemu informacje na tacy. Dodaj:
# Wyłączenie automatycznego listowania katalogów
Options -IndexesJeśli po dodaniu tej linii pojawi się błąd 500, hosting prawdopodobnie nie pozwala zmieniać Options w .htaccess. Wtedy napisz do supportu zamiast testować kolejne warianty na ślepo.
Wyłączenie edycji plików z kokpitu – DISALLOW_FILE_EDIT
Standardowo administrator może edytować pliki motywów i wtyczek prosto z kokpitu. Jeśli ktoś przejmie konto administratora, ta funkcja ułatwia mu wgranie złośliwego kodu. Na stronach klientów wyłączam ją domyślnie.
Otwórz plik wp-config.php i przed linią:
/* That's all, stop editing! Happy publishing. */dodaj:
// Wyłączenie edycji plików z poziomu kokpitu WordPressa
define( 'DISALLOW_FILE_EDIT', true );Plik wp-config.php zwykle leży w katalogu głównym WordPressa, ale może też znajdować się poziom wyżej – nie zakładaj, że zawsze jest obok .htaccess.
Po tej zmianie edytory motywów i wtyczek znikną z kokpitu. To dodatkowa warstwa ochrony, a nie antywirus – atakujący wciąż może próbować innych dróg.
Dodatkowa ochrona plików konfiguracyjnych
Jeśli serwer obsługuje odpowiednie dyrektywy, zablokuj bezpośredni dostęp do wrażliwych plików:
# Blokada bezpośredniego dostępu do wrażliwych plików
<FilesMatch "^(wp-config\.php|\.htaccess|\.htpasswd|debug\.log)$">
Require all denied
</FilesMatch>To dodatkowe zabezpieczenie, a nie zamiennik prawidłowej lokalizacji pliku .htpasswd poza publicznym katalogiem.
Prawidłowe uprawnienia plików i katalogów
Najczęściej spotkasz zalecenie 755 dla katalogów i 644 dla plików. To dobry punkt wyjścia, ale nie ma jednej wartości dla każdego hostingu – liczy się też właściciel plików, grupa i sposób uruchamiania PHP.
- Katalogi: najczęściej 755 lub 750.
- Pliki: najczęściej 644 lub 640.
- wp-config.php: w dobrze skonfigurowanym środowisku może mieć bardziej restrykcyjne uprawnienia, np. 440 lub 400.
Dokumentacja WordPressa zaleca, by pliki należały do właściwego użytkownika, a prawa zapisu były możliwie ograniczone.
Nigdy nie ustawiaj 777 ani 666 „na szybko”. Jeśli WordPress nie może zapisać pliku, sprawdź najpierw właściciela, grupę i konfigurację PHP/FPM. Gdy hosting wymaga np. 775 dla konkretnego katalogu, najpierw ustal przyczynę, a dopiero potem zmieniaj uprawnienia.
Kiedy zabezpieczenia bez wtyczek nie wystarczą
W mojej pracy z klientami te reguły traktuję jako pierwszą warstwę, nigdy jako jedyną. Są sytuacje, w których od razu rekomenduję dodatkowe mechanizmy:
- Sklep internetowy z płatnościami – konta klientów, dane osobowe, zamówienia i wiele wtyczek. Reguły .htaccess nie usuną luk w WooCommerce ani dodatkach.
- Wielu redaktorów – potrzebne jest zarządzanie rolami, kontrola sesji, monitoring zmian i procedura odbierania dostępu byłym pracownikom. Basic Auth tego nie zastąpi.
- Serwer Nginx – Nginx nie czyta plików .htaccess. Reguły trzeba ustawić w konfiguracji serwera.
- Brak dostępu do .htaccess – niektóre hostingi blokują część dyrektyw. Wtedy konfigurację robię zgodnie z możliwościami hostingu.
- Potrzeba monitoringu i alertów – .htaccess nie pokaże Ci prób logowania, zmian plików ani podejrzanego ruchu.
- Większe serwisy – tu warto rozważyć WAF, CDN z funkcjami bezpieczeństwa, monitoring i regularne skanowanie.
Najważniejsze: kilka reguł w .htaccess nie zastąpi aktualizacji. Jeśli masz podatną wersję wtyczki, ani blokada XML-RPC, ani Basic Auth tej luki nie usuną.
Najczęstsze błędy przy edycji .htaccess
Te pomyłki widzę najczęściej, gdy klienci zgłaszają się do mnie z „nagle niedziałającą” stroną:
- Edycja bez kopii zapasowej – zawsze najpierw pobierz oryginalny plik.
- Błędna ścieżka w AuthUserFile – musi to być pełna, absolutna ścieżka do pliku .htpasswd.
- Brak odpowiedniego AllowOverride – hosting może nie pozwalać na niektóre dyrektywy.
- Stara składnia Apache 2.2 – na Apache 2.4 używaj
Require. - Plik .htpasswd w publicznym katalogu – plik z hashami nie może być do pobrania z przeglądarki.
- Blokada XML-RPC bez sprawdzenia integracji – Jetpack czy aplikacja mobilna mogą przestać działać.
- Basic Auth bez HTTPS – hasło leci wtedy otwartym tekstem.
- Zły adres IP w RequireAny – wpisany adres omija dodatkowe hasło.
- Wyjątek dla zmiennego IP – ma sens tylko przy stałym adresie publicznym.
- Testy na produkcji bez planu B – miej gotową kopię i dostęp przez FTP/SFTP lub panel hostingu.
Moja zasada: jeśli po zmianie strona zwraca błąd 500, nie dokładam kolejnych reguł „na próbę”. Najpierw przywracam działającą wersję, a potem testuję zmiany pojedynczo.
Jeśli nie znasz składni Apache i nie masz wsparcia hostingu, bezpieczniej zlecić konfigurację komuś, kto zna Twój serwer. Jedna błędna dyrektywa potrafi wyłączyć całą witrynę.
Podsumowanie
- Reguły .htaccess odrzucają część żądań na poziomie serwera, zanim zajmie się nimi WordPress.
- Blokada xmlrpc.php wyłącza ten punkt dostępu – przed wdrożeniem sprawdź, czy go nie używasz.
- HTTP Basic Auth dodaje drugą warstwę ochrony przed wp-login.php, ale wpływa też na wpisy chronione hasłem.
- Basic Auth stosuj wyłącznie z HTTPS.
- Przy stałym IP możesz użyć RequireAny, by pominąć dodatkowe hasło ze swojego adresu.
- Plik .htpasswd trzymaj poza publicznym katalogiem i generuj przez htpasswd -B (bcrypt).
- Options -Indexes wyłącza listowanie katalogów, a DISALLOW_FILE_EDIT – edycję plików z kokpitu.
- Uprawnienia 644/755 to punkt wyjścia, nie uniwersalna reguła.
- Żadna z tych metod nie zastępuje aktualizacji, kopii zapasowych i monitoringu.
Potrzebujesz pomocy z zabezpieczeniem WordPressa?
Skonfiguruję .htaccess, .htpasswd i wp-config.php pod Twój hosting, sprawdzę, czy zabezpieczenia działają, i pomogę przywrócić stronę, jeśli coś pójdzie nie tak.
Zadzwoń: 785 351 565 Napisz do mnieOdbieram od poniedziałku do piątku w godz. 8:00–20:00.
Najczęściej zadawane pytania
Czy wyłączenie XML-RPC jest bezpieczne dla każdej strony?
Nie. Jeśli korzystasz z Jetpacka, aplikacji mobilnej WordPress lub innej integracji opartej na XML-RPC, najpierw sprawdź jej wymagania. Jeśli Twoja strona z XML-RPC nie korzysta, blokada to prosty sposób na zamknięcie zbędnego punktu wejścia.
Jak sprawdzić, czy reguła .htaccess działa?
Przy blokadzie XML-RPC wejdź na twojastrona.pl/xmlrpc.php – powinieneś zobaczyć 403 Forbidden. Przy Basic Auth wejdź na wp-login.php – przeglądarka powinna wyświetlić dodatkowe okno logowania. Błąd 500 oznacza, że trzeba przywrócić kopię .htaccess.
Czym różni się składnia Apache 2.2 od Apache 2.4?
Apache 2.2 używał dyrektyw Order, Allow i Deny. Apache 2.4 wprowadził model oparty na Require (np. Require all denied, Require valid-user, Require ip). Na nowych serwerach używaj Require.
Gdzie bezpiecznie umieścić plik .htpasswd?
Poza katalogiem dostępnym z przeglądarki, np. w katalogu domowym użytkownika hostingu. Nie umieszczaj go w public_html. Dyrektywa AuthUserFile musi wskazywać dokładną ścieżkę do pliku.
Czy Basic Auth zablokuje moje wpisy chronione hasłem?
Tak, może. WordPress obsługuje hasła do wpisów przez wp-login.php?action=postpass, więc czytelnicy zobaczą dodatkowe okno logowania. Jeśli publikujesz takie wpisy, wybierz inne zabezpieczenie logowania.
Czy mogę wyłączyć Basic Auth dla mojego adresu IP?
Tak. W Apache 2.4 połącz Require ip z Require valid-user w bloku RequireAny. Stosuj to tylko przy stałym, zaufanym publicznym adresie IP.
Czy wyjątek dla IP działa z Cloudflare lub innym proxy?
Nie zawsze. Za CDN lub reverse proxy serwer może widzieć adres pośrednika zamiast Twojego. Przed użyciem Require ip sprawdź, jaki adres faktycznie rozpoznaje Apache.
Czy zabezpieczenia bez wtyczek wystarczą dla sklepu internetowego?
Nie. To element hardeningu, ale sklep wymaga też aktualizacji WordPressa, WooCommerce i dodatków, porządku w kontach, kopii zapasowych, a często także WAF. Reguły serwera nie naprawiają luk w kodzie wtyczek.
Jak wygenerować plik .htpasswd?
Najlepiej narzędziem htpasswd na serwerze, np. htpasswd -B -c /home/twojanazwa/.htpasswd-kamproweb kampro_admin. Generator online traktuj jako rozwiązanie awaryjne i nie używaj w nim haseł z innych usług.
Czy plik wp-config.php zawsze znajduje się obok .htaccess?
Nie. Zwykle jest w katalogu głównym WordPressa, ale może też leżeć poziom wyżej. Przed edycją sprawdź rzeczywistą strukturę katalogów.
Stan na październik 2026. Konfiguracje hostingów, wersje Apache/LiteSpeed i funkcje WordPressa mogą się zmieniać – przed wdrożeniem na produkcji sprawdź ustawienia swojego serwera lub skonsultuj je z hostingiem.
Kamil Witek – tworzę i zabezpieczam strony WordPress dla firm, Opole.
