bazaar
Une boutique e-commerce sur un micro-framework PHP maison - sans Laravel ni Symfony. Catalogue, panier en session, Stripe Checkout, comptes clients et un back-office complet, sur des sessions durcies et uniquement des requêtes préparées.
Une boutique e-commerce sur un microframework PHP fait main, sans Laravel, sans Symfony. Un catalogue de produits, un panier en session, Stripe Checkout, des comptes clients et un back-office d'administration complet. Avec les paiements il n'y a pas de place pour les raccourcis, donc les sessions sont durcies et seules des requêtes préparées atteignent la base.
Introduction
Les grands frameworks PHP gèrent beaucoup de choses pour vous, sécurité comprise. bazaar y renonce volontairement : un microframework écrit de zéro signifie que vous gardez vous-même les sessions, construisez vous-même les requêtes et êtes le seul responsable d'empêcher les données clients de fuir. Il n'y a pas de couche qui répare en silence vos oublis.
C'est un projet sur la discipline, pas sur les fonctionnalités. La boutique fait exactement ce qu'on attend d'une boutique, mais toute sa valeur réside dans le fait que chaque point de contact avec l'utilisateur et la base est une frontière qu'il faut surveiller à la main et consciemment.
Une descente délibérée vers le PHP nu
Quand vous retirez le framework, le filet de sécurité qui vit d'habitude dans la configuration par défaut part avec lui. L'échappement, la protection des sessions, la liaison des paramètres dans les requêtes, rien de tout cela n'est plus gratuit. bazaar traite cela comme une leçon : pour écrire une boutique sécurisée en PHP nu, vous devez comprendre chaque menace dont un framework vous protège normalement.
La discipline est ici revigorante, parce qu'il n'y a nulle part où cacher un raccourci. Si vous avez collé une requête à partir de chaînes quelque part ou fait confiance à des données de formulaire, cela se voit tout de suite, et la responsabilité est sans ambiguïté la vôtre.
Du panier au paiement
des produits avec prix, catégories et un état de publication.
des lignes gardées côté serveur, immunisées contre la falsification dans le formulaire.
le paiement confié à un prestataire spécialisé, sans toucher aux données de carte.
historique des commandes pour le client, un panneau d'administration complet pour le propriétaire.
La clé est dans les étapes deux et trois. Le panier vit côté serveur, donc les prix et les quantités ne sont pas ce qui est venu du navigateur mais ce que la boutique elle-même a décidé. Le paiement va à Stripe, donc un numéro de carte ne passe jamais par notre code, ce qui retire du système la part de responsabilité la plus dangereuse.
La frontière que vous surveillez à la main
La boutique accepte des paiements, donc les erreurs ne sont pas cosmétiques. Pas une seule requête n'est assemblée à partir de chaînes. Des requêtes préparées uniquement, toujours, car c'est la seule frontière qui arrête réellement une injection SQL.
Chaque entrée venant de l'extérieur est traitée comme hostile jusqu'à ce qu'elle soit liée à un paramètre ou échappée. Ce n'est pas de la paranoïa mais la seule façon dont une boutique sans le filet d'un framework peut être sûre.
Le résultat n'est pas une boutique plus riche en fonctionnalités que celles sur Laravel, mais une boutique dont vous comprenez la sécurité jusqu'au bout, parce que vous l'avez construite vous-même. Chaque frontière est explicite, chaque requête paramétrée, et l'élément le plus sensible, les données de carte, ne vit pas du tout dans notre système.
Où est la frontière et par quoi elle est gardée
| Frontière | Gardée par |
|---|---|
| Entrée de formulaire | validation et échappement |
| Requête à la base | requêtes préparées uniquement |
| Panier | côté serveur, session durcie |
| Données de carte | confiées à Stripe, jamais chez nous |
Plus de projets
D'autres réalisations de la même catégorie - découvrez comment nous abordons des défis similaires.
Vous avez un projet similaire ?
Contactez-nous - le devis est gratuit et arrive sous une heure.