Programowanie z AI bez znajomości PHP: 7 błędów, które drogo kosztują

W skrócie: Z pomocą AI w godzinę powstaje formularz PHP, portal klienta albo skrypt kopii zapasowej, który działa. Czy jest też bezpieczny, tego po nim nie widać. W dużym badaniu firmy Veracode kod wygenerowany przez AI zawierał lukę bezpieczeństwa w 45 % zadań testowych. Kto nie umie czytać kodu, zauważy to dopiero wtedy, gdy strona zostanie zhakowana – albo gdy kopii zapasowej w razie awarii nie da się przywrócić.

Sam używam AI codziennie. Jest szybka, cierpliwa i zna każdą funkcję. Ale pisze kod, który wygląda wiarygodnie, a nie kod, który jest sprawdzony. Różnicę rozpozna tylko ktoś, kto wie, czego szukać. W tym artykule pokazuję błędy, które najczęściej widzę w PHP zbudowanym przez AI – i ile mogą kosztować.

Co mówią badania

• Veracode, GenAI Code Security Report 2025: Ponad 100 modeli językowych rozwiązało 80 zadań programistycznych. W 45 % przypadków kod zawierał lukę bezpieczeństwa. Przed cross-site scripting (XSS) nie było zabezpieczonych 86 % przykładów.
• Badanie Stanford (Perry i in., ACM CCS 2023): Uczestnicy z asystentem AI w czterech z pięciu zadań częściej pisali niebezpieczny kod niż grupa bez AI – a jednocześnie częściej uważali swój kod za bezpieczny.
• Wymyślone pakiety (Spracklen i in.): Modele AI polecają biblioteki, które w ogóle nie istnieją – przy modelach komercyjnych średnio co najmniej 5,2 %, przy modelach otwartych 21,7 %. Atakujący rejestrują takie nazwy i wypełniają je złośliwym kodem („slopsquatting“).

Problem nie polega więc na tym, że AI źle programuje. Problem w tym, że brzmi pewnie – a bez doświadczenia nie ma się powodu, by jej nie ufać.

Błąd 1: Zapytanie do bazy, które każdy może przepisać

Klasyk, który AI wciąż regularnie dostarcza, zwłaszcza gdy prosi się o „prosty“ kod:

$sql = "SELECT * FROM kunden WHERE email = '" . $_GET['email'] . "'";
$ergebnis = $db->query($sql);

To działa – i pozwala każdemu odwiedzającemu wstrzyknąć przez pasek adresu własne polecenia SQL (SQL injection). W ten sposób można odczytać dane klientów, zmienić hasła albo usunąć tabele. Prawidłowo stosuje się zapytanie przygotowane (prepared statement):

$abfrage = $db->prepare('SELECT * FROM kunden WHERE email = ?');
$abfrage->execute([$_GET['email']]);

Różnica to jedna linia. Kto jej nie zna, ten jej nie widzi.

Błąd 2: Wyświetlanie danych bez zabezpieczenia

Księga gości, formularz kontaktowy, lista klientów w panelu administracyjnym: wszędzie tam, gdzie wpisane dane są ponownie wyświetlane, trzeba je zabezpieczyć (escapować). Jeśli tego brakuje, atakujący może wstrzyknąć JavaScript, który uruchomi się w przeglądarce Państwa pracowników – z ich uprawnieniami. Właśnie ta luka (XSS) była najczęstsza w badaniu Veracode.

echo $kunde['name'];                                  // niebezpieczne
echo htmlspecialchars($kunde['name'], ENT_QUOTES);   // bezpieczne

Błąd 3: Hasła, które da się odtworzyć

AI chętnie sięga po md5() albo sha1(), bo tak jest w milionach starych tutoriali. Takie hashe przy popularnych hasłach da się złamać w bardzo krótkim czasie. PHP od wersji 5.5 ma wbudowane, bezpieczne rozwiązanie:

$hash = password_hash($passwort, PASSWORD_DEFAULT);
if (password_verify($eingabe, $hash)) { /* zalogowany */ }

Błąd 4: Upload plików jako otwarte drzwi

„Zbuduj mi upload dokumentów klientów“ – i AI zapisuje plik pod oryginalną nazwą w katalogu strony. Jeśli ktoś wgra plik o nazwie rechnung.php, na Państwa serwerze leży potem program, który każdy może uruchomić. Właśnie tak na strony trafia wiele tylnych furtek (backdoorów). Z mojej praktyki: na zhakowanych stronach WordPress regularnie znajduję w katalogu uploadów pliki PHP, które nigdy nie powinny się tam znaleźć.

Upload jest bezpieczny dopiero wtedy, gdy sprawdzany jest typ i zawartość pliku, plik dostaje nową nazwę, trafia poza publiczny katalog, a PHP w ogóle nie może być tam wykonywane.

Błąd 5: Dane dostępowe w kodzie

Hasło do bazy danych, klucz API operatora płatności, dostęp SMTP: AI chętnie wpisuje je bezpośrednio do pliku, bo tak najszybciej działa. Jeśli ten plik trafi do publicznego repozytorium Git, na forum wsparcia albo jako config.php.bak do katalogu strony, dostępy są stracone. Do tego pasuje błąd numer sześć: włączone komunikaty błędów (display_errors) na stronie produkcyjnej, które każdemu odwiedzającemu zdradzają ścieżki plików i nazwy baz danych.

Błąd 6: Biblioteki, które nie istnieją

Gdy zapyta się o rozwiązanie nietypowego problemu, AI czasem poleca pakiet Composer albo npm o przekonującej nazwie – który nigdy nie istniał. Kto po prostu skopiuje polecenie, w najlepszym razie nic nie zainstaluje, w najgorszym pakiet, który atakujący umieścił właśnie pod tą nazwą. Proszę sprawdzać każdy pakiet: kto go utrzymuje, od kiedy istnieje, ilu ludzi go używa?

Błąd 7: Kopia zapasowa, która w razie awarii nie działa

To najdroższy błąd, bo wychodzi na jaw dopiero wtedy, gdy wszystko inne już się posypało. „Napisz mi skrypt kopii zapasowej“ szybko daje coś, co co noc tworzy plik. Czy da się z niego odtworzyć stronę, nikt nie sprawdza. Typowe przypadki z praktyki:

• Kopia leży w katalogu strony. Plik taki jak backup.sql czy backup.zip w publicznym katalogu może pobrać każdy, kto zgadnie nazwę – ze wszystkimi danymi klientów. Takie pliki to ulubiony cel automatycznych skanerów.
• Kopia leży na tym samym serwerze. Jeśli serwer zostanie zhakowany, zaszyfrowany albo wypowiedziany, kopia znika razem z nim.
• Tylko pliki, bez bazy danych – albo odwrotnie. Strona bez bazy danych to pusta skorupa, baza danych bez wgranych zdjęć i dokumentów również.
• Zepsute polskie i niemieckie znaki. Eksport bazy danych z błędnym kodowaniem znaków da się wprawdzie zaimportować, ale z „Müller“ robi się „Müller“ – w każdym rekordzie.
• Kopia zawiera atakującego. Kto po włamaniu przywróci ostatni backup, często od razu przywraca też tylną furtkę, bo była tam już kilka tygodni wcześniej.
• Nigdy nie przetestowana. Kopia zapasowa jest kopią dopiero wtedy, gdy raz udało się ją przywrócić. Wcześniej jest tylko nadzieją.

Ile może kosztować taki błąd

Rachunek składa się z kilku pozycji i żadna z nich nie jest mała:

• Czyszczenie: znaleźć i usunąć złośliwy kod, zamknąć lukę, odnowić wszystkie dostępy. U mnie zaczyna się to od 490 € netto za typową stronę – przy oprogramowaniu na zamówienie z niejasnym kodem często znacznie więcej.
• Przestój: brak zapytań, rezerwacji i zamówień, dopóki strona jest offline albo Google przed nią ostrzega. Jeśli hosting zablokuje pakiet, często padają też skrzynki e-mail.
• Ochrona danych: jeśli wyciekną dane osobowe, z reguły w ciągu 72 godzin trzeba zawiadomić organ ochrony danych (art. 33 RODO/DSGVO), w pewnych przypadkach także osoby, których dane dotyczą. RODO przewiduje kary do 20 milionów euro lub 4 % światowego rocznego obrotu – w codzienności małej firmy zwykle już sam nakład pracy, porady prawne i utrata zaufania ważą wystarczająco dużo.
• Odbudowa: jeśli nie da się przywrócić czystej kopii, treści i dane trzeba żmudnie odtwarzać – albo są stracone.

Po drugiej stronie stoi przegląd przez kogoś, kto potrafi czytać kod. Kosztuje ułamek tego.

Korzystać z AI – ale właściwie

Nikomu nie radzę rezygnować z AI. To świetne narzędzie, jeśli traktuje się je jak szybkiego, ale niedoświadczonego kolegę:

• Nie publikować niczego, czego się nie rozumie. Proszę kazać sobie wyjaśnić każdą linię, zanim trafi na serwer.
• Celowo pytać o bezpieczeństwo: „Czy ten kod jest podatny na SQL injection, XSS albo niebezpieczny upload?“ Badanie Stanford pokazuje: kto podchodzi do AI krytycznie, dostaje bezpieczniejszy kod.
• Sprawdzać każdy pakiet, zanim się go zainstaluje.
• Przechowywać kopie zapasowe poza serwerem i przynajmniej raz testowo je przywrócić.
• Zlecić przegląd przed uruchomieniem – zwłaszcza gdy w grę wchodzą dane klientów, logowanie albo płatności.

Jeśli to już się stało

Proszę niczego nie usuwać na własną rękę i nie przywracać starego backupu, zanim nie będzie jasne, kiedy atakujący dostał się do środka. Proszę zabezpieczyć aktualny stan i poszukać pomocy. Więcej w artykule Zhakowany WordPress; w przypadku aplikacji PHP na zamówienie: Programista PHP. Żeby aktualizacje i kopie zapasowe w ogóle nie zostawały w tyle: Opieka techniczna WordPress.

Powiązany temat: Kreator, AI czy strona robiona od podstaw – różnica wychodzi w drugim roku.

Stan: październik 2026. Źródła: Veracode, 2025 GenAI Code Security Report (lipiec 2025); N. Perry, M. Srivastava, D. Kumar, D. Boneh: „Do Users Write More Insecure Code with AI Assistants?“, ACM CCS 2023 (arXiv:2211.03622); J. Spracklen i in.: „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“ (USENIX Security 2025); art. 33 i art. 83 RODO (DSGVO).