Izolacja danych w e-commerce: front vs backend

W klasycznym sklepie na PHP wszystko — strony, logika, panel i baza danych — działa w jednej aplikacji. Włamanie przez słabą wtyczkę oznacza zwykle dostęp do całości: zamówień, danych klientów, a czasem i serwera. Architektura headless pozwala to zmienić, bo zmusza do pytania: kto naprawdę potrzebuje jakich danych?

Ten wpis należy do serii Headless commerce.

Zasada najmniejszych uprawnień

Każdy element systemu dostaje tylko tyle, ile potrzebuje:

• storefront — potrzebuje publicznych danych: produktów, cen, dostępności i treści. Nie potrzebuje dostępu do bazy ani do listy klientów,
• warstwa pośrednia (BFF) — przetwarza koszyk, zamówienia i sesje, ale z użyciem ograniczonych kluczy,
• zaplecze — trzyma dane i logikę, dostępne tylko dla warstwy pośredniej i administratorów przez VPN,
• baza danych — dostępna wyłącznie dla zaplecza, z kontem o minimalnych uprawnieniach.

Co widzi front, a czego nigdy nie powinien

Front (czyli to, co wykonuje się w przeglądarce klienta) może znać:

• katalog produktów i ceny publiczne,
• stan własnego koszyka i zamówienia po uwierzytelnieniu,
• dane własnego konta klienta.

Nie powinien natomiast mieć dostępu do kluczy administracyjnych, danych innych klientów, struktury bazy czy ustawień zaplecza.

Tokeny i klucze o ograniczonym zakresie

Zamiast jednego „klucza do wszystkiego” stosuje się klucze o wąskich uprawnieniach: jeden tylko do odczytu produktów, inny do tworzenia zamówień, kolejny do wystawiania dokumentów. Wyciek jednego klucza ma wtedy ograniczone skutki. Klucze trzymamy po stronie serwera (zmienne środowiskowe, menedżer sekretów), nigdy w kodzie dostępnym dla przeglądarki.

Płatności poza sklepem

Dane kart płatniczych nie powinny przechodzić przez Twoje serwery. Korzystamy z przekierowania do operatora płatności lub osadzonych pól hostowanych przez operatora, co znacząco zmniejsza zakres odpowiedzialności i ryzyko. W sklepie zostaje jedynie identyfikator transakcji i jej status.

Segmentacja środowisk

Środowisko testowe nie powinno zawierać prawdziwych danych klientów, a produkcyjne nie powinno być dostępne dla programistów „na stałe”. Warto rozdzielić środowiska, uprawnienia i klucze oraz stosować anonimizowane kopie do testów.

Izolacja a RODO

Mniej miejsc z danymi osobowymi to mniej ryzyka i łatwiejsza kontrola. Wyraźny podział, rejestr dostępów i logi pozwalają szybciej wykryć problem oraz wykazać, kto i kiedy miał dostęp do danych. Szczegóły prawne konsultuj z prawnikiem, ale architektura może Ci w tym realnie pomóc.

Izolacja a integracje (ERP, CRM)

Systemy firmowe łączą się z zapleczem przez prywatne kanały (VPN, zamknięte API), a nie przez publiczny front. Dzięki temu dane z ERP, takie jak ceny hurtowe czy stany, nie wyciekają do publicznej warstwy. Szersze omówienie integracji: ERP, CRM i sklep w meblarstwie.

Co dalej

Aby izolacja miała sens, trzeba ją zrealizować na odpowiedniej infrastrukturze — o tym mówi wpis o VPS dla sklepu headless. Poprzednia część: backend poza internetem. Zainteresowany? Zobacz headless commerce i napisz do nas.