Discussion :

[BKaernel]

Bonjour. Si un spécialiste JS a un avis sur la question ?

J'ai crée un site statique pour une petite boutique, avec une page PANIER. Le panier marche avec LocalStorage et des boutons addToCart en JS.
Un bouton SDK Paypal permet de finaliser le paiement. Je récupère le total via JS et je l’intègre dans le script PayPal.
La seule indication publique est l'ID client dans le chemin du script.

Selon vous, cela pose il un problème de sécurité ? Je sais bien qu'il est possible de changer le prix du total via la console, mais je ne vois pas l'intérêt de la manœuvre
car au final le total payé via Paypal ne correspondra pas au produit et le vendeur le verras bien.

Pour l'instant, je suis assez serein sur la procédure car je ne transmet aucun code, token confidentiel mais peut-être que je suis dans le faux.
J'ai une certaine maitrise de JS mais je ne suis pas non plus un expert.

Si certain-e parmi ont des connaissances poussées en JS et peuvent confirmer ou infirmer ? Merci.

[Toufik83]

Bonsoir,

Pour répondre directement, votre intuition technique est correcte sur le fonctionnement, mais elle présente un risque de sécurité métier important.


En déléguant le calcul du total exclusivement au JavaScript (côté client), vous reposez sur ce qu'on appelle la confiance aveugle envers le client.

Un utilisateur malveillant peut ouvrir la console, modifier la variable total de votre script ou altérer le contenu du localStorage avant de cliquer sur le bouton. Il peut ainsi transformer un panier de 500 € en une transaction de 1 €.

Vous avez raison sur un point, quand vous ne transmettez aucun token confidentiel (Secret Key).
C'est le bon réflexe, mais la sécurité ne concerne pas seulement la confidentialité des clés, elle concerne aussi l'intégrité des données (s'assurer que le prix n'a pas été modifié en chemin).

Si vous restez sur votre solution actuelle, assurez-vous que le mail de confirmation de commande envoyé au vendeur affiche très clairement le message : ATTENTION, Vérifiez que le montant payé correspond bien au prix catalogue avant expédition.

Sinon, vous pouvez passer par les PayPal Server-Side SDKs, au lieu de passer le montant directement dans le bouton, vous utilisez l'option createOrder pour appeler un script (en PHP par exemple, puisque c'est très léger à déployer) qui fera l'appel API v2/checkout/orders de manière sécurisée.

[BKaernel]

Désolé d'insister mais en quoi le fait de pouvoir changer via le LocalStorage le prix du panier est un soucis ?

Si le prix est changé, 1€ au lieu de 500€, la somme reçu sur le compte de la boutique sera bien 1€ et ils verront bien que le prix ne correspond pas.
Si il s'agissait d'une grande boutique, je n'aurais pas la même logique, mais là c'est artisanal. Donc, peu de vente et chaque vente est visée.

Je ne vois pas l'intérêt d'une personne de changer le prix, car cela annulerait de fait la vente puisque le prix demandé ne serait pas bon.
Je ne sais pas si mes explications sont bonnes ?

PS: C'est un site statique. Donc PHP, c'est mort. C'est du JS.
ps 2: J'utilise deja un bouton SDK paypal.
PS 3 : Une petite api consulté en JS avec une base de donnée SQLITE serait une solution ?

[Doksuri]

immaginons : je fais un panier a 500e, je transforme en 1e
je paye
la commande est envoyee a la preparation, et le 1e est envoye a la compta

le gars prepare la commande et l'envoi.
le lendemain le gars de la compta : "n'envoi pas la commande !" ... trop tard

je fais maintenant la sourde oreille, et adieu les 499e manquant

---

autre scenario (qui semble etre ton cas)
je fais un panier a 500e, je le transforme en 1e
je paye
le gars du magasin est le meme que celui qui prepare la commande...
il voit 1e, et se dit qu'il y a un probleme
il ne fait pas la commande, et maintenant doit lancer un processus de remboursement

---

scenario 3
je fais un panier a 500e, je le transforme en 250e
je paye
le gars du magasin ne fait pas trop attention.. voit un gros montant
il prepare la commande, et l'envoi


la regle absolue est qu'il ne faut jamais faire confiance a de la donnee provenant du client (ordinateur/telephone/autre), il faut toujours faire les actions sur un serveur.
mais si tu n'as pas de back.. je ne vois pas trop de solution viable

[BKaernel]

la régle absolue est qu'il ne faut jamais faire confiance a de la donnee provenant du client (ordinateur/telephone/autre), il faut toujours faire les actions sur un serveur.
mais si tu n'as pas de back.. je ne vois pas trop de solution viable

J'ai bien précisé qu'il s'agissait d'une PETITE BOUTIQUE ARTISANALE.
Les scénarios qui tu élabores sont justes évidemment, mais dans ce cas là ils sont peu probables puisqu'il y a 1 seule et même personne qui verrait vite le soucis.

Dans le cas numéro 2 , tu peux aussi envoyer un message. Merci de terminer votre paiement... en attente.

Le site est statique mais envoyé sur un serveur qui propose des BDD etc...
Si vraiment je suis obligé, je pense a (SQLITE avec une mini api en php (ou un petit framework ?)) mais j'aimerais m'éviter ce travail.

Et je ne vois toujours pas le soucis de pouvoir changer le localStorage dans mon cas (je reprécise).

[BKaernel]

Au final... J'ai crée une micro-api qui calcule le total du panier en JS. C'est assez "simple".
J'utilise une base de donnée SQLITE pour les ID produit et le prix.

Le total panier n'est jamais calculé par la navigateur en JS mais bien sur un serveur.
Même si une modification du total serait flagrante dans mon cas, je vais me conformer aux règles de base.

J'ai aussi ajouter un script pour reloader la page (je connais l'ajax mais je préfére comme çà) quand le localStorage est modifié.

[gabi7756]

Au final... J'ai crée une micro-api qui calcule le total du panier en JS. C'est assez "simple".
J'utilise une base de donnée SQLITE pour les ID produit et le prix.

Avec une auth ?

[BKaernel]

Avec une auth ?

Non, l'api est ouverte. Il n'y a rien de confidentiel et ça m'évite du travail en plus.
J'ai trouvé un bon système de backend : https://pocketbase.io/
Plutôt que de faire une api sans interface ou plutôt avec.. mais de façon détourné.

PocketBase donne la possibilité d'ajouter des scripts JS donc, c'est parfait.
Il possible de l'utiliser chez eux ou de l'héberger. C'est mieux que Firebase de Google.

[gabi7756]

Et depuis l'API tu peux modifié le prix des articles ?

[BKaernel]

Et depuis l'API tu peux modifié le prix des articles ?

L'API est un backend ou plutôt le contraire. C'est comme si tu pouvais visualiser ta base de donnée et la construire en visuel.

Après, c'est une base de donnée. Tu as toutes les routes que tu veux. Voir, modifier, poster, updater... Comme une BDD quoi.
Soit tu le fait de ton site statique. Soit en direct dans l'interface PocketBase.