Plik .htaccess działa jak strażnik serwera Apache lub LiteSpeed – kontroluje dostęp do wybranych plików i katalogów WordPressa. Aby go zabezpieczyć, zablokuj dostęp do samego pliku oraz do danych konfiguracyjnych, a każdą zmianę poprzedź kopią zapasową. Literówka w regule może wywołać błąd 500.
Jak przygotować się do edycji pliku .htaccess?
W większości instalacji WordPressa plik znajduje się w katalogu głównym witryny, na przykład w public_html albo w katalogu przypisanym do domeny. Pliki zaczynające się od kropki mogą być ukryte w menedżerze plików lub kliencie FTP, dlatego włącz opcję wyświetlania ukrytych elementów.
Przed zmianą pobierz plik na komputer i zapisz jego kopię pod inną nazwą. Edytuj go w zwykłym edytorze tekstu, zapisując jako UTF-8 bez BOM. Własne reguły umieszczaj poza sekcjami # BEGIN WordPress i # END WordPress, ponieważ WordPress może nadpisać zawartość pomiędzy tymi znacznikami.
Bezpieczna procedura wygląda następująco:
- Utwórz kopię pliku – pobierz oryginalny
.htaccessi zachowaj go lokalnie. - Dodaj jedną grupę reguł – nie wprowadzaj wielu zmian naraz, aby łatwiej znaleźć przyczynę problemu.
- Zapisz plik w poprawnym formacie – nazwa musi brzmieć dokładnie
.htaccess, bez dodatkowego rozszerzenia. - Sprawdź witrynę – otwórz stronę główną, kilka podstron, panel WordPressa i pliki, których dotyczy zmiana.
Uwaga: błąd składni w pliku .htaccess może spowodować błąd serwera 500. Jeśli strona przestanie działać, połącz się z serwerem przez FTP lub menedżer plików i zmień nazwę pliku na przykład na
.htaccess_backup. Jeśli witryna wróci, przyczyną jest jedna z ostatnich reguł.
Po przywróceniu działania możesz odtworzyć kopię zapasową albo dodawać reguły pojedynczo. Jeżeli błąd 500 utrzymuje się mimo zmiany nazwy pliku, problem może leżeć w konfiguracji serwera. W takiej sytuacji skontaktuj się z administratorem hostingu.
Jak zabezpieczyć .htaccess i pliki systemowe WordPress?
Blokada dostępu do samego pliku .htaccess
Dodaj regułę w głównym pliku .htaccess. Zablokuje ona żądania kierowane bezpośrednio do plików konfiguracyjnych tego typu:
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>Dyrektywa Require all denied jest składnią stosowaną w Apache 2.4+. Jeżeli hosting korzysta ze starszej konfiguracji Apache, może wymagać składni opartej na Order i Deny. Nie mieszaj obu wariantów bez potwierdzenia, że serwer je obsługuje.
Ochrona wp-config.php
Plik wp-config.php zawiera między innymi dane dostępowe do bazy danych. Zablokuj jego odczyt z poziomu przeglądarki:
<Files "wp-config.php">
Require all denied
</Files>Reguła nie odbiera administratorowi dostępu przez FTP, SFTP ani menedżer plików. Blokuje jedynie bezpośrednie żądania HTTP do tego pliku.
Wyłączenie wykonywania PHP w uploads
Katalog wp-content/uploads służy głównie do przechowywania obrazów i innych załączników. Umieść w nim osobny plik .htaccess z regułą blokującą wykonywanie skryptów PHP:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>Nie dodawaj tej reguły do głównego katalogu WordPressa, ponieważ zablokowałaby wykonywanie podstawowych plików systemu. Przed zastosowaniem sprawdź też, czy używany motyw lub wtyczka nie wymaga uruchamiania PHP w katalogu uploads.
Najczęściej stosowane reguły ochronne dotyczą:
- pliku
.htaccess, aby nie można było pobrać jego zawartości przez przeglądarkę, - pliku
wp-config.php, w którym znajdują się dane bazy danych, - katalogu
wp-content/uploads, gdzie warto zablokować wykonywanie PHP, - plików dzienników i innych dokumentów zawierających informacje o konfiguracji serwera.
Jak wzmocnić ochronę WordPressa za pomocą .htaccess?
Wyłączenie XML-RPC
XML-RPC umożliwia zewnętrznym aplikacjom komunikację z WordPressem. Jeśli nie korzystasz z aplikacji publikujących treści poza panelem WordPressa, możesz ograniczyć dostęp do pliku xmlrpc.php:
<Files "xmlrpc.php">
Require all denied
</Files>Blokada może ograniczyć działanie aplikacji mobilnych, zewnętrznych narzędzi publikacyjnych lub usług korzystających z XML-RPC. Po jej wprowadzeniu sprawdź, czy wszystkie używane integracje nadal działają.
Ograniczenie dostępu do wp-admin według IP
Jeżeli masz stały adres IP, możesz ograniczyć dostęp do katalogu wp-admin. Regułę umieść w pliku .htaccess znajdującym się wewnątrz tego katalogu:
<RequireAll>
Require ip 203.0.113.25
</RequireAll>Zastąp 203.0.113.25 własnym adresem IP. To rozwiązanie nie sprawdzi się przy dynamicznym IP, ponieważ po jego zmianie utracisz dostęp do panelu i będziesz musiał zmodyfikować plik przez FTP lub menedżer plików.
Blokada hotlinkowania obrazów
Hotlinkowanie polega na osadzaniu obrazów z Twojego serwera na innych stronach. Może zwiększać zużycie transferu. Poniższy przykład wymaga zastąpienia example.com własną domeną:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC,L]Reguła blokuje żądania obrazów pochodzące z innych domen. Warto pamiętać, że część przeglądarek i usług nie wysyła nagłówka Referer, dlatego przykład pozostawia takie żądania dozwolone.
Dodatkowe hasło do panelu
Drugą warstwę logowania można skonfigurować za pomocą pliku .htpasswd. Umieść go poza publicznym katalogiem witryny, a w pliku .htaccess katalogu wp-admin użyj:
AuthType Basic
AuthName "Panel administracyjny"
AuthUserFile /home/uzytkownik/.htpasswd
Require valid-userŚcieżka w dyrektywie AuthUserFile musi być pełną ścieżką istniejącą na Twoim serwerze. Nie kopiuj przykładowej wartości bez zmian. Hasło w pliku .htpasswd powinno być inne niż hasło do konta WordPress.
Co sprawdzić po zapisaniu zmian?
Otwórz stronę w nowej karcie lub oknie prywatnym i sprawdź funkcję, której dotyczyła reguła. W przypadku blokad możesz przetestować adres pliku bezpośrednio, ale nie wykonuj testów destrukcyjnych ani nie blokuj własnego dostępu bez przygotowanej kopii.
Notatka ekspercka: .htaccess jest tylko jedną warstwą ochrony. Aktualizuj WordPressa, motywy i wtyczki, stosuj silne hasła, ograniczaj liczbę kont administracyjnych i wykonuj regularne kopie zapasowe. Przed wdrożeniem bardziej złożonych reguł sprawdź, czy serwer działa na Apache lub LiteSpeed – na Nginx plik .htaccess nie jest obsługiwany.
