bazaar
Ein E-Commerce-Shop auf einem eigenen PHP-Mikroframework - ohne Laravel und Symfony. Katalog, Warenkorb in der Session, Stripe Checkout, Kundenkonten und ein vollständiges Admin-Backend, auf gehärteten Sessions und ausschließlich Prepared Statements.
Ein E-Commerce-Shop auf einem eigenen PHP-Microframework, ohne Laravel, ohne Symfony. Ein Produktkatalog, ein Warenkorb in der Session, Stripe Checkout, Kundenkonten und ein vollständiges Admin-Backend. Bei Zahlungen gibt es keinen Platz für Abkürzungen, also sind die Sessions gehärtet und nur Prepared Statements erreichen die Datenbank.
Einführung
Große PHP-Frameworks erledigen vieles für Sie, Sicherheit inbegriffen. bazaar verzichtet bewusst auf sie: Ein von Grund auf geschriebenes Microframework bedeutet, dass Sie die Sessions selbst hüten, Abfragen selbst bauen und selbst dafür verantwortlich sind, dass Kundendaten nicht auslaufen. Es gibt keine Schicht, die im Stillen Ihre Versäumnisse flickt.
Es ist ein Projekt über Disziplin, nicht über Funktionen. Der Shop tut genau das, was Sie von einem Shop erwarten, aber sein ganzer Wert steckt darin, dass jeder Berührungspunkt mit dem Nutzer und der Datenbank eine Grenze ist, die Sie von Hand und bewusst bewachen müssen.
Ein bewusster Abstieg zu nacktem PHP
Wenn Sie das Framework abziehen, geht das Sicherheitsnetz mit, das sonst in der Standardkonfiguration steckt. Escaping, Session-Schutz, das Binden von Parametern in Abfragen, nichts davon ist mehr gratis. bazaar behandelt das als Lektion: Um einen sicheren Shop auf nacktem PHP zu schreiben, müssen Sie jede Bedrohung verstehen, vor der Sie ein Framework normalerweise abschirmt.
Die Disziplin ist hier erfrischend, weil es nirgends einen Ort gibt, an dem man eine Abkürzung verstecken könnte. Wenn Sie irgendwo eine Abfrage aus Strings zusammengeflickt oder Formulardaten vertraut haben, sieht man es sofort, und die Verantwortung ist eindeutig Ihre.
Vom Warenkorb zur Zahlung
Produkte mit Preisen, Kategorien und einem Veröffentlichungsstatus.
Positionen serverseitig gehalten, immun gegen Manipulation im Formular.
die Zahlung einem spezialisierten Anbieter übergeben, ohne Kartendaten anzufassen.
Bestellhistorie für den Kunden, ein vollständiges Admin-Panel für den Besitzer.
Der Schlüssel liegt in Schritt zwei und drei. Der Warenkorb lebt serverseitig, also sind Preise und Mengen nicht das, was aus dem Browser kam, sondern das, was der Shop selbst festgelegt hat. Die Zahlung geht an Stripe, also läuft eine Kartennummer nie durch unseren Code, was den gefährlichsten Teil der Verantwortung aus dem System entfernt.
Die Grenze, die Sie von Hand bewachen
Der Shop nimmt Zahlungen an, also sind Fehler nicht kosmetisch. Keine einzige Abfrage wird aus Strings zusammengefügt. Nur Prepared Statements, immer, denn das ist die eine Grenze, die eine SQL-Injection wirklich stoppt.
Jede Eingabe von außen wird als feindlich behandelt, bis sie an einen Parameter gebunden oder escaped ist. Das ist keine Paranoia, sondern die einzige Art, wie ein Shop ohne das Netz eines Frameworks sicher sein kann.
Das Ergebnis ist kein Shop, der reicher an Funktionen ist als die auf Laravel, sondern ein Shop, dessen Sicherheit Sie bis zum Grund verstehen, weil Sie sie selbst gebaut haben. Jede Grenze ist explizit, jede Abfrage parametrisiert, und das empfindlichste Element, die Kartendaten, lebt gar nicht in unserem System.
Wo die Grenze ist und wodurch sie bewacht wird
| Grenze | Bewacht durch |
|---|---|
| Formulareingabe | Validierung und Escaping |
| Datenbankabfrage | nur Prepared Statements |
| Warenkorb | serverseitig, gehärtete Session |
| Kartendaten | an Stripe übergeben, nie bei uns |
Weitere Projekte
Weitere Projekte aus derselben Kategorie - sehen Sie, wie wir ähnliche Herausforderungen angehen.
Haben Sie ein ähnliches Projekt?
Melden Sie sich - ein Angebot ist kostenlos und kommt innerhalb einer Stunde.