bazaar
Sklep e-commerce na własnym mikroframeworku PHP - bez Laravela i Symfony. Katalog, koszyk w sesji, Stripe Checkout, konta klientów i pełne zaplecze administracyjne, na hartowanych sesjach i wyłącznie prepared statements.
Sklep e-commerce na własnym mikroframeworku PHP, bez Laravela i Symfony. Katalog produktów, koszyk w sesji, Stripe Checkout, konta klientów i pełne zaplecze administracyjne. Przy płatnościach nie ma miejsca na skróty, więc sesje są hartowane, a do bazy idą wyłącznie prepared statements.
Wprowadzenie
Duże frameworki PHP załatwiają za ciebie mnóstwo rzeczy, w tym bezpieczeństwo. bazaar rezygnuje z nich celowo: mikroframework napisany od zera oznacza, że sam pilnujesz sesji, sam budujesz zapytania i sam odpowiadasz za to, żeby dane klienta nie wyciekły. Nie ma warstwy, która po cichu łata twoje niedopatrzenia.
To projekt o dyscyplinie, a nie o funkcjach. Sklep robi dokładnie to, czego oczekujesz od sklepu, ale cała jego wartość siedzi w tym, że każdy punkt styku z użytkownikiem i z bazą jest granicą, której trzeba pilnować ręcznie i świadomie.
Świadome zejście na goły PHP
Kiedy odejmiesz framework, znika też siatka bezpieczeństwa, która zwykle jest w domyślnej konfiguracji. Escaping, ochrona sesji, wiązanie parametrów w zapytaniach, to wszystko przestaje być darmowe. bazaar traktuje to jako lekcję: żeby napisać bezpieczny sklep na gołym PHP, musisz rozumieć każde zagrożenie, przed którym framework zwykle cię zasłania.
Dyscyplina jest tu ożywcza, bo nie ma gdzie schować skrótu. Jeśli gdzieś skleiłeś zapytanie ze stringów albo zaufałeś danym z formularza, to widać od razu, a odpowiedzialność jest jednoznacznie twoja.
Od koszyka do płatności
produkty z cenami, kategoriami i stanem publikacji.
pozycje trzymane po stronie serwera, odporne na majstrowanie w formularzu.
płatność oddana wyspecjalizowanemu dostawcy, bez dotykania danych karty.
historia zamówień dla klienta, pełen panel administracyjny dla właściciela.
Klucz jest w kroku drugim i trzecim. Koszyk żyje po stronie serwera, więc ceny i ilości nie są tym, co przyszło z przeglądarki, tylko tym, co sklep sam ustalił. Płatność idzie do Stripe, więc numer karty nigdy nie przechodzi przez nasz kod, co usuwa najgroźniejszy fragment odpowiedzialności z systemu.
Granica, której pilnujesz ręcznie
Sklep przyjmuje płatności, więc błędy nie są kosmetyczne. Do bazy nie trafia ani jedno zapytanie sklejone ze stringów. Wyłącznie prepared statements, zawsze, bo to jedyna granica, która realnie zatrzymuje wstrzyknięcie SQL.
Każde wejście z zewnątrz jest traktowane jak wrogie, dopóki nie zostanie związane parametrem albo zescapowane. To nie paranoja, tylko jedyny sposób, w jaki sklep bez frameworkowej siatki może być bezpieczny.
Efektem nie jest sklep bogatszy w funkcje niż te na Laravelu, tylko sklep, którego bezpieczeństwo rozumiesz do końca, bo sam je zbudowałeś. Każda granica jest jawna, każde zapytanie parametryzowane, a najbardziej wrażliwy element, czyli dane karty, w ogóle nie żyje w naszym systemie.
Gdzie jest granica i czym pilnowana
| Granica | Czym pilnowana |
|---|---|
| Wejście z formularza | walidacja i escaping |
| Zapytanie do bazy | wyłącznie prepared statements |
| Koszyk | po stronie serwera, hartowana sesja |
| Dane karty | oddane Stripe, nigdy u nas |
Więcej projektów
Inne realizacje z tej samej kategorii - zobacz, jak podchodzimy do podobnych wyzwań.
Masz podobny projekt?
Napisz do nas - wycena jest bezpłatna i wraca w godzinę.