Dodatek działa. To jeszcze nic nie znaczy

Asystent AI pisze kod, który robi to, o co go poprosisz. Pole w kasie się pojawia, raport się generuje, przycisk usuwa rekord. Na tym zwykle kończy się test, bo z punktu widzenia właściciela sklepu wszystko jest w porządku.

Tyle że nikt nie poprosił asystenta, żeby kod był odporny na kogoś, kto celowo wpisze w formularz coś innego niż adres e-mail. Veracode w raporcie z 2025 roku sprawdził ponad sto modeli językowych na 80 zadaniach programistycznych i w 45 procentach przypadków wygenerowany kod zawierał podatność z listy OWASP Top 10. Modele coraz lepiej piszą kod, który się kompiluje. Z bezpieczeństwem jest gorzej.

W CS-Carcie dochodzi jeszcze jedna rzecz. Rdzeń ma dobre mechanizmy ochronne, ale część z nich działa tylko wtedy, gdy dodatek korzysta z nich we właściwy sposób. Asystent tego nie wie, chyba że ktoś mu to powie. Poniżej pięć miejsc, w których najczęściej coś się rozjeżdża.

Zapytanie do bazy sklejone z formularza

To klasyka. Dodatek ma wyszukać zamówienia po adresie e-mail, więc asystent skleja zapytanie z tym, co przyszło z formularza:

$orders = db_get_array(
    "SELECT order_id, total FROM ?:orders WHERE email = '" . $_REQUEST['email'] . "'"
);

Działa, dopóki ktoś nie wpisze w pole fragmentu kodu SQL. Wtedy zapytanie robi coś zupełnie innego, niż planowałeś, a w skrajnym przypadku wyciąga dane wszystkich klientów. Funkcje bazy w CS-Carcie mają do tego gotowe znaczniki: ?s dla tekstu, ?i dla liczby, ?a dla listy. Rdzeń sam zabezpiecza wartość, zanim trafi do zapytania:

$orders = db_get_array(
    "SELECT order_id, total FROM ?:orders WHERE email = ?s",
    $_REQUEST['email']
);

Jeśli w kodzie dodatku widzisz $_REQUEST, $_GET albo $_POST doklejone kropką do treści zapytania, to jest pierwsze miejsce do poprawy.

Wyłączone zabezpieczenie w szablonie

CS-Cart domyślnie zabezpiecza wszystko, co szablon Smarty wyświetla na stronie. Kod HTML wpisany przez klienta w notatce do zamówienia pokaże się jako zwykły tekst, a nie wykona w przeglądarce.

Asystent AI często to psuje w dobrej wierze. Gdy pole ma pokazać pogrubienie albo link, a pokazuje znaczniki, najprostsza poprawka to dopisanie nofilter:

{$order_info.notes nofilter}

Problem rozwiązany, tylko że teraz każdy klient może w notatce do zamówienia umieścić skrypt, który wykona się w przeglądarce administratora otwierającego to zamówienie w panelu. To jest XSS, a przed nim modele w badaniu Veracode nie zabezpieczyły kodu w 86 procentach prób. nofilter ma sens tylko przy treści, którą tworzy sam administrator albo którą dodatek wcześniej oczyścił. Przy danych od klientów i sprzedawców nie powinien się pojawiać.

CS-Cart chroni formularze przed atakiem CSRF, czyli przed sytuacją, w której obca strona wysyła żądanie w imieniu zalogowanego administratora. Robi to tokenem dołączanym do każdego formularza w panelu. Jest jednak haczyk: rdzeń sprawdza token tylko przy żądaniach POST.

Asystent, który ma dodać przycisk usuwania, często robi z niego zwykły link:

if ($mode == 'delete') {
    db_query("DELETE FROM ?:my_addon_items WHERE item_id = ?i", $_REQUEST['item_id']);
}

Taki link zadziała też wtedy, gdy administrator kliknie go w mailu albo gdy obca strona wstawi go jako obrazek. Token nie zostanie sprawdzony, bo to nie jest POST. Wszystko, co zmienia albo usuwa dane, powinno działać wyłącznie przy wysłaniu formularza:

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
    if ($mode == 'delete') {
        db_query("DELETE FROM ?:my_addon_items WHERE item_id = ?i", $_REQUEST['item_id']);
    }
}

Na froncie sklepu jest jeszcze ostrzej, bo tam CS-Cart domyślnie sprawdza token tylko w wybranych miejscach, takich jak logowanie i profil klienta. Dodatek z własnym formularzem na froncie musi sam zgłosić, że jego formularz ma być chroniony.

Panel bez uprawnień

W panelu CS-Cart możesz dać pracownikom ograniczone uprawnienia, na przykład obsługę zamówień bez dostępu do ustawień. Dodatek, który wprowadza nowy ekran w panelu, powinien zgłosić go w schemacie uprawnień.

Jeśli tego nie zrobi, rdzeń uzna, że ten ekran nie wymaga żadnych uprawnień, i wpuści na niego każdego administratora. Pracownik działu obsługi, który miał widzieć tylko zamówienia, zobaczy wtedy na przykład eksport danych klientów albo ustawienia integracji z kluczami API. Asystent AI prawie nigdy nie dopisuje tego schematu sam, bo dodatek działa bez niego bez zarzutu.

Sprzedawca widzi cudze zamówienia

W Multi-Vendorze każdy sprzedawca ma swój panel i powinien widzieć wyłącznie swoje produkty, zamówienia i klientów. Rdzeń pilnuje tego we własnych ekranach, dokładając do zapytań warunek z identyfikatorem sprzedawcy.

Dodatek napisany przez asystenta, który nie wie, że pracuje w marketplace, pobiera dane bez tego warunku. Raport sprzedaży w panelu sprzedawcy pokazuje wtedy obroty całego marketplace’u, a lista klientów zawiera kupujących od konkurencji. To nie jest teoretyczne ryzyko, tylko błąd, który widać od razu po zalogowaniu na konto drugiego sprzedawcy. Wystarczy to sprawdzić.

Dodatek, który przestaje działać po aktualizacji

Ostatni problem nie dotyczy włamań, ale kosztuje równie dużo. Asystent AI, żeby zmienić wygląd karty produktu albo kasy, chętnie kopiuje cały szablon rdzenia i przerabia go w kopii. Działa to do pierwszej aktualizacji CS-Carta. Potem rdzeń ma nową wersję szablonu, a sklep dalej wyświetla starą kopię z dodatku, więc nowe funkcje się nie pojawiają, a czasem kasa przestaje działać.

CS-Cart ma na to hooki szablonów, czyli miejsca, w które dodatek wstawia tylko swój fragment. Zmiana zrobiona przez hook zwykle przeżywa aktualizację. Kopia całego pliku prawie nigdy.

Co możesz sprawdzić sam

Nie trzeba być programistą, żeby wyłapać część tych błędów. Zanim wgrasz dodatek na sklep produkcyjny, zrób kilka rzeczy:

  1. Przeszukaj pliki dodatku pod kątem $_REQUEST, $_GET i $_POST i zobacz, czy któreś z nich jest doklejane kropką do zapytania SQL.
  2. Przeszukaj szablony pod kątem słowa nofilter i przy każdym trafieniu zapytaj, skąd pochodzi wyświetlana treść.
  3. Sprawdź, czy przyciski usuwania i zmiany statusu wysyłają formularz, a nie są zwykłymi linkami.
  4. Zaloguj się na konto pracownika z ograniczonymi uprawnieniami i sprawdź, czy widzi ekrany dodatku, których widzieć nie powinien.
  5. W Multi-Vendorze zaloguj się jako dwóch różnych sprzedawców i porównaj, co widzi każdy z nich.
  6. Wgraj dodatek najpierw na kopię sklepu i przejdź na niej całą ścieżkę zakupową, z płatnością włącznie.

Możesz też poprosić tego samego asystenta AI, żeby sprawdził swój kod pod kątem tych punktów. Pomaga, ale nie zastępuje przeglądu, bo model, który popełnił błąd, często go nie widzi.

Kiedy warto oddać kod do przeglądu

Gdy dodatek dotyka zamówień, płatności, kont klientów albo przyjmuje dane z formularza, warto, żeby przed wdrożeniem przejrzał go ktoś, kto zna CS-Carta od środka. Robimy to od lat przy własnych dodatkach i przy dodatkach, które klienci przynoszą do poprawy, a dziś coraz częściej są to dodatki pisane z pomocą AI. Przegląd kończy się raportem z konkretnymi miejscami do poprawy, który zostaje u Ciebie, nawet jeśli poprawki zrobisz sam.

Przegląd kodu jednego dodatku kosztuje od 900 zł netto, a w ramach opieki nad sklepem CS-Cart sprawdzamy nowe dodatki na bieżąco, zanim trafią do sklepu.