Czym jest wp-config.php i dlaczego ma tak duże znaczenie

wp-config.php to jeden z najważniejszych plików w instalacji WordPressa. Zawiera dane, bez których witryna nie uruchomi się poprawnie, a jednocześnie przechowuje informacje o dużej wartości z punktu widzenia bezpieczeństwa.

W tym pliku WordPress trzyma przede wszystkim:

• dane dostępu do bazy danych MySQL lub MariaDB,
• adres serwera bazy danych,
• prefiks tabel w bazie,
• klucze i sole bezpieczeństwa,
• ustawienia debugowania,
• wybrane parametry środowiskowe i konfiguracyjne.

To właśnie dlatego wp-config.php należy do najbardziej wrażliwych elementów całej instalacji. Jeśli osoba nieuprawniona uzyska do niego dostęp, może zyskać wgląd w dane potrzebne do przejęcia witryny albo do dalszych ataków na serwer i bazę danych.

W praktyce wyciek tego pliku może prowadzić do bardzo poważnych konsekwencji. Atakujący może:

• połączyć się z bazą danych i odczytać treści, konta użytkowników oraz konfigurację,
• próbować wstrzyknąć złośliwy kod lub zmodyfikować dane w bazie,
• przejąć konta administratorów, jeśli zdobędzie wystarczające informacje pomocnicze,
• uzyskać dostęp do poufnych danych klientów, zamówień lub ustawień sklepu,
• wykorzystać ujawnione informacje do eskalacji ataku poza sam WordPress.

Ważne jest także to, że wp-config.php nie służy tylko do połączenia z bazą danych. Często zawiera również elementy, które pomagają w diagnostyce i utrzymaniu środowiska. Jeśli zostaną ujawnione, mogą ułatwić analizę struktury serwera i przygotowanie bardziej precyzyjnego ataku.

Dlatego ochrona tego pliku nie jest dodatkiem do bezpieczeństwa WordPressa, lecz jednym z jego fundamentów. Nawet dobrze zabezpieczona witryna traci dużą część odporności, jeśli jej najważniejszy plik konfiguracyjny jest zbyt łatwo dostępny.

Jakie dane mogą być zagrożone, gdy ktoś uzyska dostęp do pliku

Jeśli wp-config.php trafi w niepowołane ręce, zagrożone są nie tylko ustawienia samego WordPressa, ale też dane całego środowiska, w którym działa witryna. To plik, który często otwiera drogę do dalszej eskalacji ataku, zwłaszcza na hostingu współdzielonym, gdzie jeden błąd konfiguracji może ujawnić więcej, niż zakłada administrator.

W pierwszej kolejności ryzykujesz ujawnienie danych potrzebnych do połączenia z bazą danych:

• nazwy użytkownika bazy,
• hasła do MySQL lub MariaDB,
• adresu serwera bazy danych,
• nazwy samej bazy,
• prefiksu tabel, który ułatwia identyfikację struktury instalacji.

To wystarcza, aby atakujący mógł próbować połączyć się bezpośrednio z bazą i odczytać zawarte w niej treści. W praktyce oznacza to dostęp do postów, stron, ustawień, danych użytkowników, a w przypadku WooCommerce także do informacji o zamówieniach, klientach i konfiguracji sklepu.

Drugą grupą są klucze bezpieczeństwa i sole. Choć same w sobie nie są hasłem do panelu administracyjnego, mają ogromne znaczenie dla sesji, ciasteczek logowania i integralności autoryzacji. Jeśli zostaną ujawnione, można podważyć bezpieczeństwo aktywnych sesji i wymusić ponowne logowanie, a w niektórych scenariuszach przygotować grunt pod przejęcie konta.

W pliku mogą znajdować się również:

• ustawienia debugowania,
• parametry środowiskowe,
• ścieżki do katalogów i zasobów,
• niestandardowe definicje używane przez motyw lub wtyczki,
• informacje pomocne do identyfikacji infrastruktury serwera.

Te dane nie zawsze wyglądają na krytyczne, ale dla osoby atakującej są bardzo cenne. Pozwalają lepiej poznać układ serwera, wersję środowiska i sposób wdrożenia aplikacji, a to ułatwia dobór kolejnych technik ataku.

Warto pamiętać, że sam dostęp do wp-config.php często nie ogranicza się już do WordPressa. Jeżeli ktoś pozna dane logowania do bazy albo szczegóły środowiska, może próbować przejść dalej: odczytywać inne pliki, analizować konfigurację hostingu, szukać słabych punktów w kontach administracyjnych i łączyć różne błędy w jeden skuteczny atak.

Dlatego ochrona tego pliku to nie tylko sprawa prywatności. To realna bariera między zwykłą instalacją WordPressa a możliwością przejęcia całej witryny lub wycieku danych użytkowników.

Najczęstsze błędy, które narażają wp-config.php na odczyt

W praktyce większość incydentów z wp-config.php nie wynika z zaawansowanego ataku, tylko z prostych błędów administracyjnych. To dobra wiadomość, bo oznacza, że wiele ryzyk można ograniczyć szybko i bez dużych zmian w samej instalacji WordPressa.

Najczęstszy problem to zbyt liberalne uprawnienia pliku. Jeśli plik ma prawa ustawione zbyt szeroko, może zostać odczytany przez niepowołane procesy lub użytkowników na serwerze. W środowiskach współdzielonych to szczególnie niebezpieczne, bo jeden źle skonfigurowany plik potrafi ujawnić dane całej witryny.

Drugim częstym błędem jest pozostawienie pliku w miejscu, które można łatwo podejrzeć przez przeglądarkę. Sam WordPress zwykle nie wystawia go bezpośrednio, ale problem pojawia się wtedy, gdy serwer WWW ma błędną konfigurację, katalog główny nie jest odpowiednio chroniony albo dostęp do pliku omija standardowe reguły bezpieczeństwa.

Warto zwrócić uwagę także na nieprawidłową konfigurację Apache lub Nginx. Źle napisane reguły w pliku .htaccess, brak blokady dostępu do plików wrażliwych albo pomyłka w konfiguracji lokalizacji mogą sprawić, że plik stanie się dostępny mimo pozornie poprawnej struktury katalogów. Podobne ryzyko występuje, gdy hosting stosuje własne reguły, a administrator zakłada, że domyślne zabezpieczenia działają inaczej niż w rzeczywistości.

Dużym zagrożeniem są również kopie zapasowe i pliki tymczasowe. Często to nie oryginalny wp-config.php ujawnia dane, lecz jego kopia z rozszerzeniem typu .bak, .old, .save albo archiwum wrzucone do katalogu publicznego. Atakujący bardzo często skanują witryny właśnie pod kątem takich pozostałości po wdrożeniach i aktualizacjach.

Niebezpieczne bywają też stare wersje oprogramowania. Zdezaktualizowany WordPress, przestarzały panel hostingu, słaba konfiguracja PHP lub luki w wtyczkach mogą otworzyć drogę do odczytu plików, nawet jeśli sam wp-config.php jest poprawnie ustawiony. Ochrona tego pliku nie działa w próżni — zależy od całego środowiska.

W praktyce szczególnie groźne są następujące zaniedbania:

• ustawienie zbyt szerokich uprawnień dla pliku lub katalogu nadrzędnego,
• przechowywanie kopii zapasowych w katalogu publicznym,
• pozostawianie plików tymczasowych po edycji lub migracji,
• brak ochrony katalogu głównego przed listowaniem zawartości,
• nieprawidłowe reguły blokujące dostęp w .htaccess lub konfiguracji Nginx,
• poleganie wyłącznie na zabezpieczeniach hostingu bez własnej weryfikacji.

Warto pamiętać, że nawet jeśli sam plik nie jest bezpośrednio dostępny z internetu, błędna konfiguracja serwera może ujawnić go pośrednio. Dlatego bezpieczeństwo wp-config.php trzeba traktować jako efekt kilku warstw ochrony, a nie jednego ustawienia.

Jak ograniczyć dostęp do wp-config.php na poziomie systemu plików

Najprostszą i jednocześnie jedną z najskuteczniejszych metod ochrony wp-config.php jest ustawienie możliwie restrykcyjnych uprawnień pliku oraz poprawnego właściciela i grupy. Ten plik nie powinien być traktowany jak zwykły zasób aplikacji, tylko jak element zawierający dane dostępowe do całego środowiska WordPressa.

W typowych instalacjach warto dążyć do zasady najmniejszych uprawnień. Oznacza to, że plik ma być czytelny wyłącznie dla procesu, który faktycznie go potrzebuje, i niedostępny dla pozostałych użytkowników systemu. W praktyce najczęściej spotyka się trzy warianty:

• 600 — tylko właściciel może czytać i zapisywać plik; to bardzo dobre rozwiązanie, gdy PHP działa jako ten sam użytkownik, który jest właścicielem pliku,
• 640 — właściciel ma pełny dostęp, a grupa może czytać plik; przydatne w konfiguracjach, gdzie proces WWW działa w grupie przypisanej do instalacji,
• 644 — właściciel może czytać i zapisywać, a pozostali tylko czytać; to częsty kompromis na hostingach współdzielonych, ale zwykle warto sprawdzić, czy da się zejść niżej bez ryzyka problemów z działaniem strony.

Nie ma jednej uniwersalnej wartości dla każdej konfiguracji, ale bezpieczna zasada jest prosta: nie nadawaj szerszego dostępu, niż wymaga tego środowisko. Jeśli plik jest ustawiony zbyt otwarcie, rośnie ryzyko, że odczyta go inny użytkownik serwera, proces pomocniczy albo podatna wtyczka działająca w niekorzystnym kontekście.

Równie ważny jest właściciel pliku. W idealnym scenariuszu powinien nim być użytkownik związany z daną instalacją, a nie ogólny, wspólny użytkownik używany przez wiele projektów. Dzięki temu błąd w jednej witrynie nie daje automatycznie dostępu do innych plików na tym samym koncie. Na hostingu współdzielonym warto sprawdzić, czy operator pozwala na poprawne ustawienie właściciela i grupy, ponieważ bez tego nawet dobre uprawnienia mogą nie zapewnić pełnej izolacji.

Ważne są także uprawnienia katalogów nadrzędnych. Nawet jeśli sam plik ma restrykcyjne prawa, zbyt szeroki dostęp do katalogu głównego lub katalogów po drodze może ułatwić odczyt lub obejście zabezpieczeń. Bezpieczna konfiguracja obejmuje więc kontrolę nie tylko nad wp-config.php, ale też nad całym łańcuchem katalogów, w których ten plik się znajduje.

W praktyce warto zwrócić uwagę na kilka zasad:

• nie ustawiaj uprawnień typu 666 lub innych bardzo otwartych wartości,
• unikaj zapisu dla grupy i innych użytkowników, jeśli nie jest to absolutnie konieczne,
• sprawdź, czy proces WWW naprawdę potrzebuje dostępu zapisu do pliku,
• po migracji lub wdrożeniu ponownie zweryfikuj właściciela i grupę,
• kontroluj także prawa do katalogów, w których znajdują się pliki WordPressa.

Dobrym nawykiem jest wykonanie krótkiego audytu po każdej zmianie hostingu, przywróceniu kopii zapasowej albo aktualizacji środowiska. Zmiana serwera, panelu administracyjnego czy modelu uruchamiania PHP często powoduje, że dotychczas bezpieczne ustawienia przestają być optymalne. Właśnie dlatego ochrona wp-config.php powinna być regularnie weryfikowana, a nie ustawiona raz na zawsze.

Jeśli chcesz podejść do tematu technicznie poprawnie, zacznij od sprawdzenia właściciela pliku, ustawienia uprawnień na możliwie najniższy bezpieczny poziom i upewnienia się, że katalogi nadrzędne nie ujawniają zawartości ani nie pozwalają na niepotrzebny zapis. To prosty krok, ale często eliminuje największą klasę ryzyk związanych z nieuprawnionym odczytem konfiguracji WordPressa.

Przeniesienie wp-config.php poza katalog publiczny jako dodatkowa warstwa ochrony

Jednym z praktycznych sposobów ograniczenia ryzyka odczytu wp-config.php jest umieszczenie go poza katalogiem publicznym, czyli poza obszarem, który jest bezpośrednio dostępny z poziomu przeglądarki. WordPress potrafi odczytać ten plik także wtedy, gdy znajduje się on poziom wyżej niż katalog, z którego serwowane są pliki witryny. Dzięki temu nawet jeśli ktoś spróbuje wejść w jego adres URL, plik nie powinien być dostępny do pobrania.

To rozwiązanie ma szczególny sens wtedy, gdy masz kontrolę nad strukturą katalogów na serwerze i możesz zmienić lokalizację pliku bez naruszania działania strony. W praktyce najczęściej oznacza to przeniesienie konfiguracji do katalogu nadrzędnego względem public_html, www lub innego katalogu docelowego, z którego serwowany jest WordPress.

Korzyści takiego podejścia są konkretne:

• zmniejszasz ryzyko pobrania pliku przez bezpośredni adres URL,
• utrudniasz skanowanie witryny pod kątem wrażliwych plików konfiguracyjnych,
• oddzielasz warstwę aplikacyjną od warstwy publicznej,
• zyskujesz dodatkową barierę ochronną, zwłaszcza na hostingu współdzielonym.

Trzeba jednak pamiętać, że nie jest to zabezpieczenie samowystarczalne. Sam fakt przeniesienia pliku poza katalog publiczny nie zastąpi poprawnych uprawnień, właściwego właściciela pliku ani reguł blokujących dostęp po stronie serwera. Jeśli katalog nadrzędny ma zbyt szerokie prawa lub środowisko jest źle skonfigurowane, nadal mogą pojawić się problemy z odczytem konfiguracji.

Warto też uwzględnić ograniczenia zależne od hostingu. Na części serwerów współdzielonych lub w panelach o mocno ograniczonej kontroli nad strukturą katalogów przeniesienie wp-config.php może być niemożliwe albo kłopotliwe. Zdarza się również, że provider narzuca własny model uprawnień, przez co trzeba najpierw sprawdzić dokumentację hostingu, zanim wykonasz zmianę.

Jeśli planujesz takie rozwiązanie, podejdź do niego ostrożnie:

• najpierw wykonaj pełną kopię zapasową plików i bazy danych,
• sprawdź, czy WordPress w danej instalacji poprawnie odczytuje plik po przeniesieniu,
• zweryfikuj, czy nie ma dodatkowych kopii konfiguracji w katalogu publicznym,
• po zmianie przetestuj logowanie, połączenie z bazą i działanie wtyczek.

Przeniesienie wp-config.php poza katalog publiczny najlepiej traktować jako dodatkową warstwę ochrony, a nie pełne rozwiązanie problemu. To dobry krok, ale tylko wtedy, gdy idzie w parze z restrykcyjnymi uprawnieniami, poprawną konfiguracją serwera i regularną kontrolą środowiska WordPressa.

Zabezpieczenia po stronie serwera: Apache, Nginx i hosting współdzielony

Ochrona wp-config.php nie powinna opierać się wyłącznie na uprawnieniach pliku. Równie ważne są reguły po stronie serwera WWW, które blokują bezpośredni odczyt tego pliku, nawet jeśli ktoś spróbuje wejść w jego adres URL lub przeskanować katalog pod kątem wrażliwych zasobów.

W środowisku Apache najczęściej stosuje się reguły w .htaccess lub w konfiguracji vhosta, które odcinają dostęp do plików konfiguracyjnych. Przykładowo można zablokować pobieranie wp-config.php i jednocześnie wyłączyć listowanie katalogów, aby przeglądarka nie pokazywała zawartości folderów, gdy brakuje indeksu. Dobrą praktyką jest też upewnienie się, że serwer nie ujawnia plików backupów, kopii roboczych i archiwów pozostawionych po migracjach.

W przypadku Nginx podobny efekt uzyskuje się przez odpowiednie bloki location i reguły zwracające odmowę dostępu dla plików wrażliwych. Warto zadbać także o to, by w wybranych katalogach nie dało się uruchamiać PHP tam, gdzie nie jest to potrzebne. To ogranicza skutki sytuacji, w której ktoś spróbuje wykorzystać pozostawiony plik pomocniczy lub niechcianą kopię konfiguracji.

Praktyczne zabezpieczenia po stronie serwera obejmują:

• blokadę bezpośredniego dostępu do wp-config.php,
• wyłączenie listowania katalogów,
• ochronę przed wykonywaniem PHP w katalogach, które nie powinny uruchamiać skryptów,
• ograniczenie dostępu po adresie IP, jeśli panel administracyjny lub serwer jest używany w zamkniętym środowisku,
• wdrożenie WAF i reguł antybotowych, które filtrują skanowanie znanych ścieżek i próbują wykrywać automatyczne wyszukiwanie plików konfiguracyjnych.

Na hostingu współdzielonym sytuacja jest bardziej złożona, bo część zabezpieczeń zależy od operatora. Nawet jeśli Twoja instalacja jest poprawnie skonfigurowana, ryzyko może pojawić się przez błędne aliasy, niebezpiecznie wystawione backupy albo nieprawidłowe reguły na poziomie całej maszyny. Dlatego warto sprawdzić, czy hosting nie udostępnia publicznie kopii zapasowych, starych katalogów wdrożeniowych albo tymczasowych wersji plików.

W praktyce najlepiej traktować zabezpieczenia serwera jako drugą linię obrony. Jeśli plik ma dobre uprawnienia, jest poprawnie umieszczony i jednocześnie serwer blokuje jego odczyt, znacznie trudniej doprowadzić do wycieku konfiguracji. To szczególnie ważne w środowiskach wieloużytkownikowych, gdzie każda luka w konfiguracji może mieć wpływ na więcej niż jedną witrynę.

Jeżeli chcesz podejść do tego technicznie poprawnie, sprawdź najpierw, czy serwer odrzuca próby wejścia w wp-config.php, potem zweryfikuj ochronę katalogów i na końcu przejrzyj zasoby publiczne pod kątem kopii zapasowych oraz plików tymczasowych. Dopiero po połączeniu tych warstw można mówić o sensownej ochronie konfiguracji WordPressa.

Dobre praktyki dodatkowe: klucze, kopie zapasowe, monitoring i aktualizacje

Ochrona wp-config.php nie kończy się na ustawieniu uprawnień i blokad serwera. Nawet dobrze zabezpieczony plik może zostać ujawniony po incydencie, błędzie administracyjnym albo przez podatność w innym elemencie środowiska. Dlatego warto traktować bezpieczeństwo tego pliku jako część szerszego procesu utrzymania WordPressa.

Jedną z najważniejszych czynności po podejrzeniu wycieku jest rotacja kluczy bezpieczeństwa WordPressa. Dzięki temu unieważniasz istniejące sesje i zmniejszasz ryzyko, że ktoś nadal korzysta z przechwyconych ciasteczek logowania. W praktyce warto to zrobić także wtedy, gdy zmieniasz hosting, przywracasz kopię zapasową z niepewnego źródła albo wykonujesz gruntowne porządki po naruszeniu bezpieczeństwa.

Równie istotne są kopie zapasowe. Backup powinien być szyfrowany i przechowywany poza serwerem produkcyjnym, aby awaria lub atak na główny hosting nie oznaczały jednoczesnej utraty danych i kopii ratunkowej. Nie przechowuj archiwów w katalogach publicznych i regularnie sprawdzaj, czy w repozytoriach backupów nie znajdują się niepotrzebne kopie plików konfiguracyjnych.

Warto wdrożyć także monitoring integralności plików. Alert o zmianie w wp-config.php pozwala szybko wykryć nieautoryzowaną modyfikację, zanim przerodzi się ona w przejęcie witryny. Dobrym uzupełnieniem są logi serwera, które pokazują próby dostępu do wrażliwych ścieżek, skanowanie katalogów oraz nietypowe wzorce żądań.

Bezpieczeństwo tego pliku zależy również od aktualizacji całego ekosystemu. Aktualizuj WordPressa, motywy, wtyczki, PHP oraz elementy infrastruktury serwerowej. Stare wersje oprogramowania zwiększają ryzyko odczytu plików, obejścia zabezpieczeń i eskalacji uprawnień. Nawet jeśli sama konfiguracja jest poprawna, luka w dodatku lub w środowisku hostingowym może otworzyć drogę do wp-config.php.

W praktyce warto pamiętać o kilku prostych zasadach:

• po każdym incydencie zmieniaj klucze bezpieczeństwa i hasła do krytycznych usług,
• trzymaj kopie zapasowe poza serwerem produkcyjnym i szyfruj je,
• monitoruj zmiany w plikach konfiguracyjnych,
• regularnie przeglądaj logi pod kątem nietypowego dostępu,
• aktualizuj WordPress, wtyczki, motywy i PHP bez odkładania tego na później.

Takie podejście nie zastępuje twardych zabezpieczeń pliku, ale znacząco skraca czas reakcji i zmniejsza skutki ewentualnego wycieku. W praktyce to właśnie połączenie ochrony technicznej, kopii zapasowych, monitoringu i aktualizacji daje realną odporność całego środowiska WordPressa.

Jak sprawdzić, czy wp-config.php jest odpowiednio chroniony

Ochrona wp-config.php nie powinna być oparta na założeniu, że „na pewno nic się nie dzieje”. Warto regularnie sprawdzać, czy plik faktycznie jest niedostępny dla osób nieuprawnionych i czy nie istnieją obejścia, które omijają podstawowe zabezpieczenia.

Najprostszy audyt możesz wykonać samodzielnie, przechodząc przez krótką checklistę. Zacznij od próby bezpośredniego wejścia w adres pliku w przeglądarce. Jeżeli serwer zwraca treść pliku, pozwala go pobrać albo pokazuje jego zawartość, ochrona jest niewystarczająca i trzeba natychmiast zareagować.

Następnie sprawdź uprawnienia i właściciela pliku. Upewnij się, że konfiguracja jest możliwie restrykcyjna i zgodna z modelem uruchamiania PHP na Twoim hostingu. Weryfikuj nie tylko sam plik, ale też katalogi nadrzędne, bo zbyt szerokie prawa dostępu po drodze mogą osłabić całą ochronę.

Kolejny krok to przegląd reguł serwera, czyli .htaccess w Apache lub konfiguracji location w Nginx. Sprawdź, czy rzeczywiście blokują bezpośredni odczyt wrażliwych plików, wyłączają listowanie katalogów i nie dopuszczają do uruchamiania PHP tam, gdzie nie jest to potrzebne. W środowisku współdzielonym warto też potwierdzić, że operator hostingu nie wystawia publicznie kopii zapasowych, katalogów tymczasowych ani starych wersji plików.

Bardzo ważne jest również wyszukanie kopii wp-config.php oraz plików, które mogą zawierać te same dane w innej formie. Szukaj archiwów, plików tymczasowych i wariantów z rozszerzeniami typu .bak, .old, .save lub podobnymi. Często to właśnie one są łatwiejszym celem niż oryginalna konfiguracja.

Warto też przejrzeć logi serwera. Nietypowe próby dostępu do pliku, skanowanie katalogów lub powtarzające się żądania do wrażliwych ścieżek mogą świadczyć o tym, że witryna jest już sprawdzana przez boty lub napastników. Jeśli takie wpisy pojawiają się regularnie, dobrze jest włączyć dodatkowe ograniczenia, na przykład reguły WAF lub blokady po IP.

Przy audycie zwróć uwagę na następujące punkty:

• czy wp-config.php nie jest dostępny bezpośrednio z internetu,
• czy uprawnienia pliku są ustawione możliwie restrykcyjnie,
• czy właściciel i grupa są poprawnie przypisane,
• czy katalogi nadrzędne nie mają zbyt szerokich praw,
• czy serwer blokuje odczyt pliku i listowanie katalogów,
• czy w katalogach publicznych nie ma kopii zapasowych ani plików tymczasowych,
• czy logi nie pokazują prób odczytu lub skanowania wrażliwych zasobów.

Jeżeli nie masz pewności, czy konfiguracja jest poprawna, albo korzystasz z hostingu z ograniczonym dostępem do ustawień serwera, warto zlecić audyt bezpieczeństwa lub użyć narzędzi do skanowania podatności. Dla większych witryn i sklepów WooCommerce to szczególnie ważne, bo wyciek konfiguracji może szybko przełożyć się na ryzyko dla danych klientów i całej infrastruktury.

Najlepsze efekty daje połączenie kilku warstw: restrykcyjnych uprawnień, poprawnej konfiguracji serwera, kontroli kopii zapasowych i monitoringu zmian. Dopiero wtedy można mówić o realnie dobrej ochronie wp-config.php.

FAQ

Czy wp-config.php powinien być całkowicie niewidoczny z internetu?

Tak, plik nie powinien być możliwy do pobrania ani wyświetlenia w przeglądarce. Nawet jeśli nie da się go całkowicie ukryć w sensie technicznym, należy skutecznie zablokować bezpośredni dostęp i ograniczyć możliwość odczytu do procesów serwera.

Jakie uprawnienia dla wp-config.php są uznawane za bezpieczne?

Najczęściej stosuje się możliwie najmniej otwarte uprawnienia, zwykle 600, 640 lub w niektórych środowiskach 644, zależnie od właściciela pliku i konfiguracji hostingu. Kluczowe jest, by plik był czytelny tylko dla użytkownika serwera i nie był dostępny do zapisu dla niepowołanych procesów.

Czy przeniesienie pliku poza katalog publiczny wystarczy?

To dobra dodatkowa warstwa ochrony, ale nie wystarcza sama w sobie. Nadal trzeba zadbać o uprawnienia, konfigurację serwera, aktualizacje i ochronę kopii zapasowych.

Czy można zmienić nazwę wp-config.php na inną?

Nie jest to standardowe rozwiązanie i zwykle nie jest zalecane, bo WordPress oczekuje konkretnej lokalizacji i nazwy pliku lub mechanizmu ładowania konfiguracji. Bezpieczniejsze są sprawdzone metody ograniczania dostępu i poprawna konfiguracja serwera.

Co zrobić po podejrzeniu wycieku wp-config.php?

Należy natychmiast zmienić hasła do bazy danych, zaktualizować klucze bezpieczeństwa WordPressa, sprawdzić integralność plików i logi serwera, a także zweryfikować, czy nie doszło do modyfikacji kont administratorów lub wstrzyknięcia złośliwego kodu.

Sprawdź dziś uprawnienia, lokalizację i reguły dostępu dla wp-config.php, aby zamknąć jedną z najważniejszych dróg ataku na swoją witrynę WordPress.