PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD

Table des matières :

Surface d’attaque PrestaShop : APIs, modules, et pourquoi la supply chain est le vrai sujet
SBOM : définition, formats (SPDX/CycloneDX) et périmètre réel sur PrestaShop
CI/CD : mettre des “security gates” non négociables pour modules, APIs et overrides
SBOM + vulnérabilités : passer de “liste de CVE” à une décision d’exploitation réaliste
WAF : filtrage pragmatique (ModSecurity/CRS, Cloudflare, ACL HAProxy) adapté à PrestaShop
Déploiement : secrets, provenance, durcissement serveur, et capacité de rollback en moins de 10 minutes
Mise en œuvre réaliste : une check-list “PR → prod” pour sécuriser APIs et modules PrestaShop

Surface d’attaque PrestaShop : APIs, modules, et pourquoi la supply chain est le vrai sujet

Sur PrestaShop 8.x et 9.x (PHP 8.2/8.3 recommandées en 2026), la surface d’attaque ne se limite pas au front-office. Elle se concentre sur trois zones : les endpoints d’API (Webservice legacy, et les briques modernes exposées via Symfony), le back-office (authentification, permissions, endpoints AJAX), et surtout les modules tiers (code PHP + dépendances Composer, JS bundlé + dépendances npm/yarn). Le problème récurrent : le cœur limite certains vecteurs évidents, mais le modèle d’extension (hooks, overrides, contrôleurs legacy) laisse une marge énorme aux erreurs de sécurité.

Pour rendre ça concret, voici des chemins d’attaque typiques observés sur des boutiques “réelles” (pas des POC) :

Back-office : credential stuffing sur un compte employé, puis installation d’un module “utile” qui exfiltre (ou injecte) discrètement.
Endpoints AJAX legacy : un contrôleur mal protégé (token absent ou vérification insuffisante) devient une porte d’entrée (lecture/écriture, upload, SSRF).
API : clé Webservice trop permissive (toutes ressources en CRUD), réutilisée partout, non rotatée, qui finit dans des logs, un repo ou un outil d’intégration.
Supply chain modules : zip téléchargé hors canal maîtrisé, dépendance JS compromise, vendor PHP embarqué et jamais mis à jour, ou mise à jour automatique sans revue.

Côté API, PrestaShop reste historiquement dépendant du Webservice (clé API + permissions CRUD par ressource). Ça fait le job pour des intégrations basiques, mais la granularité d’autorisation est souvent trop grossière pour des scénarios “API-first” modernes (multi-tenant, scopes, rotation, expirations, mTLS). Pour remettre les concepts au bon endroit (endpoint, verbe HTTP, idempotence, pagination, etc.), gardez sous la main : Endpoint API : définition, méthodes HTTP et bonnes pratiques REST et le guide plus spécifique API Webservice PrestaShop : accès CRUD, authentification et bonnes pratiques.

Le troisième pilier, ce sont les modules. Un module “simple” transporte souvent : 1) du PHP exécuté dans le contexte full trust de la boutique, 2) des vendors Composer, 3) du JS packagé (parfois minifié, parfois non), 4) des binaires ou SDKs externes. En pratique, une grosse partie des incidents graves en e-commerce viennent de là : webskimmers, backdoors, dépendances compromises, ou vulnérabilités connues jamais patchées. Pour le contexte “2026” côté menace, le point de départ factuel est ici : Sécurité PrestaShop 2026 : webskimmers et infostealers côté serveur.

Mini-scénario (très courant en agence) : vous ajoutez un module de “tag management” ou de “chat” qui injecte une ressource JS externe. Le module est propre… mais la ressource distante change (ou est compromise) et devient un skimmer. Sans politique de provenance, sans inventaire (SBOM), et sans contrôle réseau sortant, vous ne voyez l’incident qu’au moment où la banque ou un PSP vous alerte.

SBOM : définition, formats (SPDX/CycloneDX) et périmètre réel sur PrestaShop

Un SBOM (Software Bill of Materials) n’est pas un gadget de compliance : c’est un inventaire exploitable de ce que vous déployez (composants, versions, relations). L’intérêt concret en production : quand une CVE sort, vous savez immédiatement si un module ou une image contient le composant concerné, et dans quelle version.

Sur l’écosystème PrestaShop, un SBOM utile doit couvrir au minimum :

PHP/Composer : composer.lock du core (si vous buildpez une distribution), et surtout celui de chaque module moderne.
JS : package-lock.json/yarn.lock pour les assets back-office/front-office (thèmes, modules).
Runtime : l’image Docker (ou le serveur), incluant OS packages (OpenSSL, libxml2, etc.).

Deux formats dominent : SPDX (Linux Foundation) et CycloneDX (OWASP). CycloneDX est souvent plus pratique pour l’outillage DevSecOps (scanners, plateformes de vulnérabilités) et lier dépendances + vulnérabilités. SPDX est très présent côté conformité licence.

Un point souvent sous-estimé sur PrestaShop : le périmètre SBOM doit suivre votre mode de distribution. Si vous livrez un zip de module “clé en main”, le SBOM doit décrire ce que contient réellement le zip (pas seulement votre composer.json). À l’inverse, si vous livrez des sources et que la CI construit l’artefact, le SBOM peut être produit au build et attaché à la release.

Table de cadrage simple (ce que vous devez pouvoir produire, et où) :

Objet déployé	Où est la vérité ?	Sortie attendue
Module moderne	`composer.lock` + lock JS	SBOM “repo” (CycloneDX/SPDX) versionné par tag
Image runtime (Docker)	Layers + paquets OS	SBOM “image” (CycloneDX/SPDX) archivé avec digest
Boutique “serveur” (non Docker)	OS + PHP extensions + code	Inventaire système + SBOM applicatif (au moins dépendances)

En 2026, il n’y a aucune excuse pour “ne pas pouvoir” générer un SBOM : des outils comme Syft (Anchore) ou Trivy (Aqua) sortent un SBOM depuis un repo ou une image, sans refactor. L’objectif n’est pas juste “avoir un fichier JSON”, mais de pouvoir répondre vite à des questions opérationnelles :

Ce module embarque-t-il une lib vulnérable ?
Cette CVE touche-t-elle ma prod ou seulement mes dépendances de dev ?
Quelle release (tag + hash) a été déployée sur tel environnement ?

La limite qu’il faut assumer : un SBOM ne “voit” pas tout. Si votre module inclut un vendor/ commité en dur, du code minifié sans sources, ou télécharge dynamiquement du code au runtime, votre SBOM sera incomplet ou trompeur. C’est précisément pour ça que le SBOM doit être couplé à des règles de build (CI/CD) et à une politique de revue : refuser les artefacts opaques, ou au minimum les isoler et les tracer.

Sur la gestion des dépôts et le risque de forks/imitations (un classique quand on “copie-colle” un module GitHub trouvé trop vite), vous pouvez recouper avec : PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks.

CI/CD : mettre des “security gates” non négociables pour modules, APIs et overrides

Une CI/CD sécurisée pour PrestaShop n’a rien de mystique : c’est une suite d’étapes automatisées qui empêchent de livrer du code non testé, non scanné, non traçable. Le prérequis, c’est d’exécuter vos tests dans un environnement reproductible (Docker), aligné sur la version réelle de la boutique (PrestaShop 8.1/8.2/9.x + PHP 8.2/8.3). Pour un exemple concret sur un module, regardez : ps_onepagecheckout : exécuter les tests PHPUnit avec Docker et PrestaShop.

Un pipeline “minimum viable” pour un module qui touche à l’API ou au checkout ressemble à ceci :

1) Qualité : PHP-CS-Fixer/PHPStan/Psalm + ESLint.
2) Tests : PHPUnit + tests d’intégration (containers MySQL/MariaDB).
3) SAST : Semgrep (règles PHP/Symfony) + éventuellement CodeQL.
4) Dependency scanning : composer audit + scan CVE via Trivy/Grype.
5) SBOM : CycloneDX (repo) + Syft (image).
6) Signature & provenance : cosign/Sigstore + attestation SLSA (si vous industrialisez).

Pour cadrer l’objectif (traçabilité de la supply chain), SLSA (Supply-chain Levels for Software Artifacts) est présenté par l’OpenSSF comme un framework/checklist de contrôles visant à réduire le risque de falsification, améliorer l’intégrité, et sécuriser artefacts et infrastructure de build : https://slsa.dev/. Concrètement, sans attestation de build et sans signature, un zip de module est un artefact non prouvable : vous ne pouvez pas démontrer qu’il correspond au code revu.

Deux “gates” simples (et très efficaces) à rendre non négociables sur PrestaShop :

Gate dépendances : si le lockfile change (composer.lock, package-lock.json), exiger une revue dédiée (changelog + justification), et bloquer si le build n’est pas reproductible.
Gate vulnérabilités : bloquer le merge si une vulnérabilité HIGH/CRITICAL touche une dépendance effectivement livrée (pas une dépendance de test), ou si une CVE connue concerne un composant exposé (ex. lib HTTP, parsing XML, templating).

Astuce pratique : ajoutez aussi un contrôle “anti-surprise” typique des incidents modules :

Interdire les binaires et artefacts opaques dans le zip (ex. .phar, .so, JS minifié sans sources) sauf exception documentée.
Scanner les secrets (tokens, mots de passe) avant merge, car les modules et overrides PrestaShop finissent souvent par contenir un “temp token” oublié.

Exemple minimal (GitHub Actions) : génération SBOM + scan image + publication artefacts. À adapter à votre repo, mais l’idée est simple : tout ce qui arrive en prod doit laisser des traces.

name: build-secure
on: [push]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: php-actions/composer@v6
        with:
          php_version: '8.2'
          command: install
      - run: composer audit --no-interaction
      - name: SBOM (CycloneDX)
        run: |
          php -v
          composer require --dev cyclonedx/cyclonedx-php-composer
          vendor/bin/cyclonedx-php-composer make-sbom --output-format=json --output-file=sbom-composer.json
      - name: SBOM + scan (image)
        run: |
          docker build -t mymodule:test .
          trivy image --format cyclonedx --output sbom-image.json mymodule:test
          trivy image --exit-code 1 --severity HIGH,CRITICAL mymodule:test
      - uses: actions/upload-artifact@v4
        with:
          name: security-artifacts
          path: |
            sbom-composer.json
            sbom-image.json

SBOM + vulnérabilités : passer de “liste de CVE” à une décision d’exploitation réaliste

Le piège classique, c’est de traiter le scan comme un compteur de CVE. En e-commerce, ce qui compte c’est l’exploitabilité dans votre contexte : endpoint exposé ou non, version de PHP, modules actifs, droits, présence d’un WAF, et surtout chemin d’attaque (RCE vs DoS vs info leak).

Pour prioriser, combinez au minimum CVSS (gravité) et EPSS (probabilité d’exploitation). EPSS est publié par le FIRST (Forum of Incident Response and Security Teams) comme un score probabiliste d’exploitation “in the wild” : https://www.first.org/epss/.

Une grille de décision simple (facile à appliquer à PrestaShop) :

Signal	Exemple	Décision recommandée
CVSS élevé et EPSS élevé et surface exposée	lib vulnérable utilisée par un endpoint public / API	Patch immédiat + mitigation WAF + vérif IoC
CVSS élevé, EPSS faible, non exposé	vuln dans un composant non appelé / feature désactivée	Planifier patch, documenter le risque
CVSS moyen, EPSS élevé, exposé	vecteur opportuniste (scans massifs)	Mitigation rapide (WAF/rate limit) + patch dès que possible
Vulnérabilité dans dépendance dev-only	outil CI non livré	Pas de panique : corriger, mais ne bloquez pas la prod inutilement

Côté outillage, le trio qui marche bien dans un environnement PrestaShop (monolithe + modules + parfois Docker) :

Composer : composer audit (rapide, mais limité au périmètre PHP).
Trivy : scan filesystem ou image (OS packages + libs) + génération SBOM.
Grype : alternative solide si vous êtes déjà chez Anchore (Syft + Grype).

L’intérêt du SBOM est de réduire le temps de diagnostic : au lieu de “chercher où est X” dans un dossier vendor/ ou dans une image, vous interrogez le SBOM. CycloneDX et SPDX sont conçus pour ça : identification (purl), versioning, relations. En incident response, ce gain de temps est souvent la différence entre “containment en 30 minutes” et “on cherche encore où c’est déployé”.

Sur PrestaShop, la gestion des vulnérabilités doit intégrer un point que beaucoup évitent : la dette des modules legacy. Certains modules n’ont pas de composer.lock, embarquent des libs dans classes/, et sont incapables d’être scannés proprement. Dans ce cas, votre politique doit être binaire :

soit vous migrez (module maintenu, sources disponibles, build reproductible),
soit vous isolez (désactivation, restriction réseau, WAF plus agressif, monitoring renforcé).

Pour un cadre méthodologique d’audit et de livrables, recoupez avec : Audit sécurité PrestaShop : méthodologie, livrables et durcissement.

WAF : filtrage pragmatique (ModSecurity/CRS, Cloudflare, ACL HAProxy) adapté à PrestaShop

Un WAF n’est pas là pour “corriger” un module vulnérable. Il est là pour casser des chaînes d’exploitation opportunistes (scans, injections basiques, exfiltration via payloads connus) et limiter l’impact d’une faille 0-day le temps d’un correctif. Pour comprendre les risques spécifiques côté API (logique métier exposée, surfaces multiples, auth mal cadrée), le bon point d’entrée reste l’OWASP API Security Project : https://owasp.org/www-project-api-security/.

Sur PrestaShop, c’est double : vous exposez à la fois les APIs (Webservice, endpoints custom) et des contrôleurs legacy souvent moins stricts (y compris dans des modules).

Trois implémentations réalistes selon votre stack :

Cloudflare WAF (ou équivalent CDN/WAF) : rapide à déployer, bon pour rate limiting, bot mitigation, règles L7, mais c’est un tiers (et un point de dépendance).
ModSecurity v3 + OWASP Core Rule Set : plus proche du serveur, utile si vous maîtrisez Nginx/Apache et que vous voulez des règles on-prem.
ACL HAProxy : pas un WAF complet, mais excellent pour filtrage “structural” (paths, headers, méthodes), et pour du rate limiting au niveau proxy.

Pour HAProxy, si vous exposez /api (API Platform / custom) et /api-webservice//webservice, vous pouvez déjà refuser des patterns absurdes (méthodes non attendues, user-agents vides, payloads trop gros) et imposer des limites. Pour approfondir les patterns ACL/health checks/stickiness : HAProxy : configuration avancée ACL, health checks et sticky sessions.

Exemple Nginx (rate limiting ciblé sur un endpoint API) :

limit_req_zone $binary_remote_addr zone=api_rl:10m rate=10r/s;

location ~ ^/(api|webservice)(/|$) {
  limit_req zone=api_rl burst=20 nodelay;
  client_max_body_size 1m;
  add_header X-RateLimit-Policy "10r/s" always;
  proxy_pass http://php_upstream;
}

Deux ajustements “spécial PrestaShop” pour éviter les incidents auto-infligés :

Séparez les politiques : back-office (faible volume, très sensible) ≠ API (volume plus fort) ≠ endpoints de paiement/callback (à ne pas casser). Beaucoup de faux positifs viennent de règles trop globales sur / au lieu de cibler /api, /webservice, /admin....
Préparez une liste d’exceptions minimale (et auditée) : certains PSP envoient des payloads atypiques, certains modules marketing génèrent des paramètres verbeux, etc. L’objectif est de maîtriser les exceptions, pas de les multiplier.

Ce qui casse le plus souvent en prod, ce ne sont pas les attaques, ce sont les faux positifs et les erreurs de configuration (403 partout, back-office inaccessible). Si votre WAF vous déclenche une pluie de 403, votre runbook doit être prêt : logs corrélés, whitelisting contrôlé, et test en staging. Sur les symptômes et le dépannage 403 (utile quand le WAF/ACL bloque), vous avez : Erreur 403 Forbidden : causes et dépannage étape par étape.

Enfin, côté UE/France, n’oubliez pas que les logs WAF/proxy contiennent souvent des données (IP, user-agent, parfois identifiants de session). Pensez “minimisation + rétention” et contractualisez correctement si vous passez par un CDN/WAF tiers (DPA, localisation, sous-traitance), en cohérence avec vos obligations RGPD (référence utile : CNIL, Guide de la sécurité des données personnelles, 2018).

Déploiement : secrets, provenance, durcissement serveur, et capacité de rollback en moins de 10 minutes

Sans gestion propre des secrets, SBOM/WAF/CI ne suffisent pas : une clé API Webservice qui traîne en clair dans un .env, un token dans un repo, ou des credentials MySQL réutilisés, ça annule le reste.

À minima sur PrestaShop :

Clés Webservice : permissions au plus juste (ressources nécessaires uniquement), rotation planifiée, et révocation testée (vous devez savoir “couper” une intégration proprement).
Back-office : restreindre l’accès (IP allowlist via proxy, VPN, SSO si applicable), et surveiller les créations/modifications de comptes employés.
Accès DB et SMTP : un secret par environnement, pas de réutilisation “staging = prod”, et pas de secrets dans les modules.

Sur Kubernetes, l’approche robuste est de sortir les secrets du cluster et de les synchroniser via un opérateur (et un KMS). Exemple concret côté OVHcloud : External Secrets Operator : synchroniser les secrets Kubernetes avec OVHcloud OKMS. Sur un hébergement OVHcloud plus classique, au minimum assurez-vous de la version PHP, du mode d’exécution et des paramètres de sécurité côté .ovhconfig : OVHcloud .ovhconfig : changer version PHP, moteur et mode d’exécution.

Le durcissement serveur reste un prérequis, pas une “option”. Typiquement : désactiver fonctions PHP dangereuses selon contexte, isoler les pools PHP-FPM, restreindre les permissions filesystem, activer des headers de sécurité, verrouiller SSH, et monitorer les tentatives d’accès. Pour une approche structurée “hardening + gestion CVE” côté PHP/Symfony, applicable à un serveur PrestaShop moderne (9.x embarque davantage de Symfony), vous avez : Symfony : sécuriser un serveur PHP avec hardening et gestion CVE.

Pour ajouter un repère “hygiène” reconnu en France (sans surcharger), l’ANSSI publie un guide de bonnes pratiques transverses, utile pour cadrer comptes, mises à jour, durcissement et sauvegardes : https://www.ssi.gouv.fr/guide/guide-dhygiene-informatique/.

Enfin, la capacité de rollback est une exigence de sécurité autant que de fiabilité : si un module patché casse le checkout ou si une règle WAF bloque le paiement, vous devez revenir à l’état précédent vite, sans improviser. Concrètement : artefacts versionnés, migrations DB réversibles (ou feature flags), et un plan de mise à jour rigoureux.

Un objectif réaliste “< 10 minutes” se tient si vous avez :

un artefact précédemment déployé toujours disponible (tag + zip ou image + digest),
un mécanisme de déploiement atomique (ex. release directory + symlink, ou blue/green),
des migrations DB conçues pour être compatibles sur une fenêtre (forward-only mais safe), ou un plan de restauration maîtrisé.

À recouper avec : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests et, si ça se passe mal, Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement.

Mise en œuvre réaliste : une check-list “PR → prod” pour sécuriser APIs et modules PrestaShop

Au niveau repo (module ou projet), standardisez d’abord ce qui est mesurable : verrouillage des dépendances (composer.lock, package-lock), build reproductible, et revue obligatoire sur les zones à risque (controllers, hooks sensibles, endpoints API, templates).

Check-list “PR → merge” (pragmatique, adaptée PrestaShop) :

[ ] Lockfiles présents et à jour (composer.lock, package-lock.json/yarn.lock)
[ ] Revue obligatoire sur : contrôleurs, endpoints, overrides, appels réseau sortants, manipulation panier/commande
[ ] Tests OK (unit + intégration minimale) dans un environnement proche prod
[ ] SAST OK (au moins Semgrep)
[ ] Scan dépendances OK (pas de HIGH/CRITICAL livré)
[ ] SBOM généré et archivé avec l’artefact
[ ] Preuve de provenance (au minimum : artefact généré par CI, pas “zip local”)

Si vous manipulez des flux API significatifs (import catalogue, ERP/PIM), gardez l’œil sur les points de perf qui se transforment vite en DoS involontaire (pagination, index, pools) : Performance API : index, pagination et pool de connexions. La sécurité d’une API qui time-out et sature les workers, c’est aussi une question de disponibilité.

Dans la CI, rendez le passage impossible sans : tests, SAST, scan dépendances, SBOM publié, et (si vous distribuez) signature d’artefact. Pour les images conteneurisées, appliquez un baseline de durcissement (droits minimaux, user non root, réduction surface, scan OS packages). Un bon point de départ pragmatique (même si PrestaShop n’est pas “DISA-only”) : DISA : sécuriser les images conteneurisées selon le guide officiel. Le but n’est pas la conformité théorique : c’est de supprimer les classes d’erreurs qui reviennent (capabilities inutiles, paquets superflus, shells dans des images runtime).

En prod, ne mélangez pas tout : le WAF filtre, le monitoring alerte, et l’équipe a un plan d’incident. Si vous n’avez pas de runbook, vous perdez du temps au pire moment (compromission, fuite de données, paiement bloqué). Le socle :

journaux WAF/proxy corrélés avec logs applicatifs (même horodatage, même identifiants de requête si possible),
détection d’anomalies (pics 4xx/5xx, endpoints “rarement appelés” soudain sollicités, spikes sur /webservice),
procédures de containment (désactivation module, rotation clés, bascule trafic, mise en maintenance contrôlée).

Pour cadrer ça sans folklore : Sécurité PrestaShop : plan de réponse à incident et containment immédiat. Et si vous cherchez un périmètre opérationnel (patchs, surveillance, procédures), la page factuelle à référencer côté organisation est : PrestaShop maintenance : tarifs, niveaux de service et périmètre.