Actualités

Polyfill.io : la faille supply chain qui a piraté votre Magento à votre insu — audit sécurité front-end 2026

En juin 2024, le domaine polyfill.io a été détourné en vecteur d’attaque. Deux ans plus tard, environ une boutique Magento sur cinq chez Wimakeit traîne encore cette dépendance. Audit + 6 autres failles front-end fréquentes.

12 mai 2026 7 min de lecture
#B2B #Mage-OS #Magento #Magento 2.4 #Sécurité
Polyfill.io : la faille supply chain qui a piraté votre Magento à votre insu — audit sécurité front-end 2026

TL;DR

  • En juin 2024, le domaine polyfill.io a été racheté puis transformé en vecteur d’attaque, exposant plus de 100 000 sites dont des milliers de stores Magento.
  • Deux ans plus tard, nos audits chez Wimakeit montrent que ~1 boutique Magento sur 5 que nous reprenons traîne encore une dépendance vers ce domaine ou un script tiers similaire non-audité.
  • En 2026, aucun store Magento 2.4.4+ n’a besoin de polyfills externes. Voici comment vérifier en 5 minutes, ce qui doit disparaître, et 6 autres failles front-end fréquentes.

1. L’incident polyfill.io en 30 secondes

Polyfill.io était à l’origine un service open-source légitime créé par le Financial Times, destiné à servir des polyfills JavaScript (du code qui ajoute des fonctionnalités modernes aux navigateurs anciens, IE11 en tête).

En février 2024, le domaine est racheté par la société chinoise Funnull. Quelques mois plus tard, en juin 2024, des chercheurs en sécurité (notamment Sansec et Cloudflare) découvrent que le service injecte désormais du JavaScript malveillant : redirections vers des sites de paris en ligne, scams crypto, malware ciblant les appareils mobiles selon le user-agent et la géolocalisation.

Les réactions ont été immédiates :

  • Google déréférence les sites qui chargent activement polyfill.io.
  • Cloudflare met en place une redirection automatique vers leur propre miroir propre cdnjs.cloudflare.com/polyfill/.
  • Mozilla publie une recommandation de suppression immédiate.
  • Namecheap, qui hébergeait le DNS, suspend temporairement le domaine.

Le problème : les sites web touchés n’ont jamais été notifiés. Si vous aviez <script src="https://polyfill.io/v3/polyfill.min.js"> dans votre <head>, vous chargiez du malware sans le savoir.

2. Pourquoi Magento a été particulièrement exposé

Trois raisons structurelles :

Héritage Magento 1. Beaucoup de modules tiers développés à l’époque de Magento 1 (2015-2018) intégraient polyfill.io « par sécurité » pour supporter IE9-IE11. Ces modules ont été portés sur M2 sans relire la dépendance.

Thèmes legacy. Les thèmes Luma anciens, et certains thèmes commerciaux populaires de la période 2017-2020, incluent un appel polyfill.io dans default_head_blocks.xml ou dans un fichier layout/default.xml custom.

Stack tiers chargée à l’admin. Quelques extensions de back-office (notamment des éditeurs WYSIWYG custom) chargent polyfill.io uniquement côté admin, donc invisible côté client mais exploitable contre les administrateurs eux-mêmes.

Résultat : un store Magento 2.4 modernisé proprement côté front peut quand même servir polyfill.io dans son admin, et un de vos collaborateurs peut être ciblé lors d’une session de gestion catalogue.

Vous pensez être impacté ?

Diagnostic gratuit polyfill.io en 15 min — on vous dit si votre store charge encore le script vérolé. Sans engagement.

Demander un diagnostic →

3. Comment vérifier si votre store est encore impacté

Audit grep côté serveur

# Côté code source
cd /var/www/vhosts/votre-store.be/src
grep -ri "polyfill.io" pub/ app/ vendor/ | grep -v ".git"

# Côté static deployed
grep -ri "polyfill.io" pub/static/ 2>/dev/null

Audit DOM côté client

Ouvrez n’importe quelle page de votre store, ouvrez les DevTools → Network → JS, rechargez (Ctrl+Shift+R) et cherchez polyfill dans le filtre.

Vérifiez aussi avec une ligne de console :

Array.from(document.scripts)
  .map(s => s.src)
  .filter(src => /polyfill|cdn\.|unpkg|jsdelivr/i.test(src))
  .forEach(src => console.log(src));

Tout ce qui sort doit être audité : ce sont des scripts servis depuis un CDN tiers que vous ne contrôlez pas.

4. Pourquoi on n’a plus besoin de polyfills en 2026

Magento Open Source 2.4.4+ et Mage-OS 2.0+ ne supportent officiellement plus IE11 depuis 2022. Les navigateurs ciblés sont Chrome 90+, Firefox 88+, Safari 14+, Edge 90+ (Chromium). Toutes les fonctionnalités modernes (fetch, Promise, Object.entries, Array.from, optional chaining…) sont natives dans ces navigateurs depuis au moins 2020. Aucun polyfill n’a de raison d’être chargé sur un Magento 2.4.7 / Mage-OS 2.x correctement maintenu.

L’exception : si votre boutique cible spécifiquement un marché B2B avec un parc d’ordinateurs sous Windows 7 + IE11 (rare, principalement secteur public et certains pays). Dans ce cas : auto-hébergez les polyfills via npm + bundle local, jamais via un CDN tiers.

5. Six autres failles front-end fréquentes

Pendant que vous nettoyez polyfill.io, voici ce qu’on retrouve aussi systématiquement dans nos audits de reprise :

  • jQuery zombie depuis Magento 1. Modules tiers chargeant jquery-1.x.min.js (vulnérable à plusieurs XSS connues). Magento 2.4 ships jQuery 3.6+ via requirejs.
  • Trackers tiers chargés sans audit. Google Tag Manager, Hotjar, Clarity, etc. : un audit RGPD/sécurité minimum exige de connaître ce que ces tags chargent.
  • Fonts custom hostées sur CDN non-EU. Google Fonts en direct sur fonts.googleapis.com = transfert IP utilisateur vers les USA (cf. décision LG München 2022). Hébergez en local.
  • SRI absent. Subresource Integrity valide qu’un script chargé depuis un CDN n’a pas été modifié. C’est ce qui aurait permis de bloquer polyfill.io dès la modification.
  • eval() dans des bundles minifiés. Certains modules tiers produisent du eval() qui rend l’analyse statique impossible.
  • Headers de sécurité absents. Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy : 2 stores Magento sur 3 en Belgique n’en ont aucun configuré.

6. Audit en 1 commande

Voici le script que nous utilisons en pré-audit chez Wimakeit. Vous pouvez le lancer sur votre repo Magento :

#!/bin/bash
# wmkt-audit-frontend.sh — quick front-end security pass for Magento 2.4+ / Mage-OS 2.x
ROOT="${1:-.}"
echo "=== polyfill.io references ==="
grep -rIn "polyfill\.io" "$ROOT/app" "$ROOT/vendor" "$ROOT/pub" 2>/dev/null \
  | grep -v ".git/" | head -20
echo "=== Other suspicious CDN includes ==="
grep -rIEn "src=[\"'][^\"']*(unpkg\.com|jsdelivr\.net|cdn\.jsdelivr|cdnjs\.cloudflare|google-analytics\.com/ga\.js)" "$ROOT/app" "$ROOT/vendor" 2>/dev/null \
  | head -20
echo "=== jQuery versions ==="
find "$ROOT" -name "jquery*.js" -type f 2>/dev/null | while read f; do
  ver=$(grep -o "jQuery v[0-9.]\+" "$f" | head -1)
  echo "$ver — $f"
done
echo "=== HTTP security headers (live check) ==="
read -p "Store URL (https://...): " URL
curl -sI "$URL" | grep -iE "content-security-policy|x-frame-options|strict-transport|referrer-policy|permissions-policy"

7. Comment Wimakeit traite ces sujets

Tous les modules de notre marketplace sont audités avec ce checklist avant publication : zéro dépendance CDN tiers, aucun polyfill, SRI activé sur les rares scripts externes, CSP-compatible, audit semestriel sur l’arbre de dépendances composer.json + package.json. Nos modules Hyvä-ready vont plus loin : pas de jQuery du tout (Tailwind + Alpine.js uniquement), bundle JS divisé par dix face à un module Luma équivalent.

8. Conclusion

L’épisode polyfill.io n’est pas un cas isolé. C’est la démonstration que la stack front-end d’un store Magento est aussi critique que son backend — et qu’elle est trop souvent négligée parce que peu visible. Un audit complet prend deux à six heures selon la taille du store ; le ROI sur la confiance utilisateur, le SEO (Google déréférence) et la conformité RGPD est immédiat.

Vous voulez être sûr que votre Magento est clean ?

Notre équipe à Presles (Wallonie) fait des audits sécurité front-end Magento à distance ou sur site, en français, néerlandais ou anglais.

Planifier un audit →

Pour aller plus loin : Mozilla Web Security Advisory (juin 2024), Cloudflare blog post, Sansec original disclosure, OWASP Top 10 A06:2021.

Partager

Publié le 12 mai 2026

Une question sur cet article ?

30 min, sans engagement, avec un interlocuteur technique senior.

Planifier un échange
Planifier un appel