Audyt bezpieczeństwa WordPress: Co sprawdzić przed uruchomieniem

Zanim jakakolwiek wtyczka wygenerowana przez PAGEnza trafi do instalacji WordPress użytkownika, przechodzi trzy zautomatyzowane kontrole bezpieczeństwa. Ten post wyjaśnia, czego szukają te kontrole — i dlaczego każda z nich jest ważna.

Dlaczego kod generowany przez AI wymaga audytu

Duże modele językowe są zaskakująco dobre w pisaniu wtyczek WordPress. Znają nazwy haków, rozumieją standardy kodowania WP, tworzą czytelny kod PHP. Ale popełniają też przewidywalne błędy — a te błędy to luki w zabezpieczeniach.

Najczęstsze, które widzimy:

• Używanie $_GET lub $_POST bez sanitizacji
• Brak weryfikacji jednorazowych kodów (nonce) przy przesyłaniu formularzy
• Bezpośrednie zapytania do bazy danych bez $wpdb->prepare()
• Używanie eval() lub exec() do dynamicznego zachowania
• Wyświetlanie danych użytkownika bez esc_html() lub esc_attr()

To nie są egzotyczne przypadki brzegowe. Pojawiają się regularnie w wynikach LLM — nawet z najlepszych modeli.

Etap 1: Walidacja promptu

Zanim AI napisze choćby jedną linię, analizujemy opis użytkownika. Ten krok wyłapuje dwie kategorie problemów:

Próby manipulacji — prompty próbujące skłonić AI do wygenerowania celowo złośliwego kodu. Rzeczy takie jak „zignoruj poprzednie instrukcje” lub „utwórz backdoor do testów”.

Niejasne lub niewykonalne opisy — prompty zbyt krótkie lub zbyt niejednoznaczne, aby wygenerować użyteczny kod. „Zrób wtyczkę” generuje śmieci; „Utwórz formularz kontaktowy, który wysyła zgłoszenia na adres e-mail z filtrowaniem spamu” generuje coś realnego.

Jeśli prompt nie przejdzie tej kontroli, użytkownik zobaczy konkretny komunikat o błędzie wyjaśniający dlaczego — nie ogólne odrzucenie.

Etap 2: Lintowanie PHP w izolowanym kontenerze

Gdy AI wygeneruje kod PHP, jest on wykonywany za pomocą php -l w kontenerze Docker, który jest całkowicie odizolowany od wszystkiego innego. Wyłapuje to błędy składniowe, zanim wtyczka trafi do instalacji WordPress.

Ale idziemy dalej: jeśli lintowanie zawiedzie, system nie tylko odrzuca wynik. Wysyła błąd z powrotem do AI z promptem naprawczym — to, co nazywamy leczeniem. AI widzi swój własny błąd i próbuje ponownie, do trzech razy.

Oznacza to, że użytkownicy prawie nigdy nie widzą komunikatu „generowanie nie powiodło się”. Widzą nieco dłuższy czas generowania — i działający kod.

Etap 3: Skanowanie bezpieczeństwa kodu

To najważniejszy etap. Przeprowadzamy analizę statyczną, która sprawdza:

Niebezpieczne funkcje: eval(), exec(), system(), shell_exec(), passthru() — każda z nich blokuje wydanie wtyczki.

Wektory wstrzykiwania SQL: surowe wywołania $wpdb->query() z interpolowanymi zmiennymi, brak $wpdb->prepare(), bezpośrednie użycie mysql_query().

Brakujące kontrole uprawnień: procedury AJAX, które nie wywołują current_user_can() przed wykonaniem jakichkolwiek uprzywilejowanych działań.

Brak weryfikacji jednorazowych kodów (nonce): procesory formularzy, które nie wywołują wp_verify_nonce() lub check_ajax_referer().

Niewyescape'owany wynik: echo $_GET[...], echo $user_input bez funkcji escape'ujących.

Jeśli którykolwiek z tych problemów zostanie znaleziony, wtyczka jest blokowana. Użytkownik widzi raport wymieniający dokładnie, które funkcje wywołały blokadę i dlaczego — nie tylko „nieudana kontrola bezpieczeństwa”.

Jak wygląda raport audytu

Każda wygenerowana wtyczka zawiera raport audytu bezpieczeństwa w prostym języku. Wymienia:

• Które kontrole przeszły pomyślnie (zielony)
• Które kontrole wywołały ostrzeżenia (bursztynowy) — problemy, które nie są blokujące, ale wymagają uwagi
• Wszelkie poprawki zastosowane automatycznie podczas leczenia

Raport jest generowany automatycznie i dołączany do pobieranej wtyczki. Jest przydatny zarówno dla Twojej pewności, jak i do pokazania klientom, że poważnie podchodzisz do bezpieczeństwa.

Etap 4: Walidacja podczas zapisywania

Ten etap nie jest częścią początkowego generowania — dotyczy sytuacji, gdy użytkownicy ręcznie edytują kod wtyczki w edytorze PAGEnza.

Za każdym razem, gdy zapisujesz, ponownie uruchamiany jest ten sam lint + skan bezpieczeństwa. Jeśli wprowadzisz krytyczną lukę podczas edycji, zapisanie zostanie zablokowane, dopóki jej nie naprawisz. Zapobiega to powszechnemu scenariuszowi, w którym programista dokonuje szybkiej „tymczasowej” zmiany, która pozostaje w produkcji przez dwa lata.

Ograniczenia zautomatyzowanego audytu

Zautomatyzowane skanowanie dobrze wyłapuje określony rodzaj problemów. Nie wyłapuje wszystkiego.

Błędy logiczne, zepsuta logika biznesowa i subtelne problemy z eskalacją uprawnień, które nie obejmują znanych niebezpiecznych wzorców, nadal wymagają ludzkiej weryfikacji. Jesteśmy transparentni w tej kwestii w dokumentacji — audyt nie zastępuje przeglądu bezpieczeństwa, jest to podstawa gwarantująca minimalny standard.

W przypadku wtyczek produkcyjnych obsługujących płatności lub wrażliwe dane zalecamy ręczny przegląd oprócz zautomatyzowanych kontroli. Raport audytu stanowi dobry punkt wyjścia dla ludzkiego recenzenta.