Le format SVG n’est toujours pas accepté nativement par la médiathèque de WordPress, y compris dans WordPress 7.1. Si vous tentez d’envoyer un tel fichier, WordPress affiche le message « Désolé, vous n’avez pas l’autorisation de téléverser ce type de fichier. », et ce refus a une bonne raison : la sécurité.
Voyons comment activer la prise en charge des SVG.
Selon Wikipédia, le Scalable Vector Graphics ou en français graphique vectoriel adaptable, est un format de données conçu pour décrire des ensembles de graphiques vectoriels et basé sur XML.
Autrement dit, vous pouvez agrandir l’élément à l’infini sans perte de qualité à la manière d’un fichier Adobe Illustrator.
Ce format sert surtout pour les logos, les icônes et les illustrations. Très léger et net à toutes les tailles d’écran, il est idéal pour le responsive design.
Pourquoi WordPress refuse-t-il les SVG ?
Contrairement à un JPEG ou un PNG, un SVG est un fichier texte au format XML. Il peut donc contenir des balises <script>, des attributs comme onload ou des liens vers des ressources externes. Un SVG piégé, ouvert directement dans le navigateur, peut exécuter du JavaScript avec les droits de votre nom de domaine (faille XSS). C’est pourquoi l’ajout des SVG aux types de fichiers autorisés est discuté depuis plus de dix ans sans être intégré au cœur de WordPress.
Deux approches existent :
- utiliser une extension qui nettoie chaque SVG à l’envoi (méthode recommandée, surtout si plusieurs personnes publient sur le site) ;
- autoriser les SVG par code, en réservant cette possibilité aux administrateurs et en nettoyant chaque fichier envoyé.
Méthode n°1 : avec l’extension Safe SVG
Safe SVG, maintenue par l’agence 10up, est l’extension de référence pour ce besoin. Elle :
- nettoie chaque SVG envoyé avec la bibliothèque svg-sanitizer, qui supprime scripts et attributs dangereux ;
- affiche un aperçu des SVG dans la médiathèque ;
- permet de choisir quels rôles peuvent envoyer des SVG.
Installez-la depuis Extensions > Ajouter une extension et activez-la : les SVG sont aussitôt acceptés et nettoyés. Par défaut, tous les comptes autorisés à téléverser des fichiers, auteurs compris, peuvent en envoyer ; vous pouvez réserver cette possibilité à certains rôles dans Réglages > Médias. L’extension SVG Support est une alternative également très répandue.
Méthode n°2 : autoriser les SVG sans extension
Si vous êtes seul à administrer le site et que vous n’envoyez que des SVG de confiance (exportés depuis votre logiciel de dessin ou fournis par votre graphiste), vous pouvez vous passer d’extension. Ajoutez le code ci-dessous dans un mu-plugin, par exemple wp-content/mu-plugins/wpc-svg-uploads.php, plutôt que dans le fichier functions.php de votre thème : l’autorisation reste ainsi active si vous changez de thème.
Ce code agit à quatre niveaux :
- le filtre
upload_mimesajoute le SVG aux types de fichiers autorisés, uniquement pour les comptes qui peuvent gérer les réglages du site (les administrateurs). Les autres rôles, auteurs compris, reçoivent toujours le message d’erreur de WordPress ; - le filtre
wp_check_filetype_and_extrègle le cas où PHP identifie le fichier commetext/plainau lieu deimage/svg+xml, par exemple quand le SVG commence par un commentaire. Sans lui, WordPress refuse l’envoi, puisqu’il compare le type réel du fichier à celui attendu ; - les filtres
wp_handle_upload_prefilteretwp_handle_sideload_prefilternettoient chaque SVG avant son enregistrement, qu’il soit envoyé depuis la médiathèque, l’éditeur de blocs ou l’API REST. Seuls les éléments de dessin sont conservés : les balises<script>et<foreignObject>, les animations, les attributs commençant paron(onload,onclick…), les liensjavascript:et les appels à des fichiers externes (<use>,<image>,@import) disparaissent. Un fichier qui n’est pas un SVG valide, ou qui déclare des entités XML, est refusé ; - le filtre
wp_upload_bitsrefuse les SVG envoyés par XML-RPC, qui échapperaient au nettoyage.
Ce nettoyage écarte les pièges les plus courants, mais il reste plus sommaire que celui de Safe SVG. Avant d’envoyer un SVG d’origine inconnue, ouvrez-le dans un éditeur de texte et vérifiez l’absence de balise <script> ou d’attributs commençant par on. Au moindre doute, préférez Safe SVG.
Avec le filtre wp_check_filetype_and_ext, inutile d’ajouter une déclaration <?xml version="1.0" encoding="utf-8"?> en tête de vos fichiers, une astuce qui servait uniquement à influencer la détection du type MIME par PHP.
Avec la méthode par code, WordPress n’enregistre ni miniature ni dimensions pour vos SVG. La vue grille de la médiathèque les affiche correctement, mais là où WordPress génère lui-même la balise d’image, par exemple dans la vue liste de la médiathèque, le SVG reçoit une largeur et une hauteur de 1 pixel. Safe SVG gère les aperçus dans la médiathèque ; sinon, voici comment corriger les erreurs d’affichage des SVG.
Et pour de simples icônes ?
Si vous cherchez seulement à afficher des pictogrammes (flèche, enveloppe, téléphone mobile, partage…), pas besoin d’autoriser les SVG. Depuis WordPress 7.0, le bloc Icône insère des icônes SVG issues d’une bibliothèque intégrée au cœur. Depuis WordPress 7.1, les développeurs peuvent y ajouter leurs propres collections d’icônes via une API dédiée (fonction wp_register_icon_collection()).
Questions fréquentes
WordPress accepte-t-il les SVG nativement ?
Non. WordPress 7.1 n’autorise toujours pas l’envoi de SVG dans la médiathèque. La demande est suivie dans le ticket n°24251 du Trac de WordPress, toujours ouvert. Le bloc Icône, lui, s’appuie sur une bibliothèque de SVG intégrée au cœur.
Autoriser les SVG est-il dangereux ?
Cela dépend de qui les envoie. Un SVG peut contenir du code JavaScript : réservez l’envoi aux administrateurs et faites nettoyer les fichiers, par une extension comme Safe SVG ou par le code de la méthode n°2.
Pourquoi WordPress refuse-t-il mon SVG malgré le code ?
Vérifiez d’abord que vous êtes connecté avec un compte administrateur. Si c’est le cas, PHP ne détecte peut-être pas le fichier comme image/svg+xml : le filtre wp_check_filetype_and_ext de la méthode n°2 corrige ce cas. Enfin, le code refuse les fichiers qui ne sont pas des SVG valides ou qui déclarent des entités XML (<!ENTITY) : réenregistrez-les sans ces déclarations depuis votre logiciel de dessin.
15 réponses
Petite question, j’ai bien téléchargé et activé le plug-in svg, (tous essayés). À chaque fois, l’intégration fonctionne dans ma bibliothèque mais une fois que je place mon image dans mes branding, elle y est et quand je « save option » ma l’image disparait, elle est illisible et n’apparaît pas dans le site alors qu’elle est bien dans ma bibliothèque ?
Soit le serveur supporte mal le format SVG, soit le SVG est mal formaté…
Oui le SVG est le mal incarné… sauf si c’est vous qui créez vos propres fichiers. Dans ce cas c’est trop cool de pouvoir le gérer directement dans WP (avec SVG Support par exemple). Il faut donc savoir ce que l’on fait et si possible nettoyer les fichiers que l’on télécharge par ailleurs (ouvrir dans Illusrator et ré-enregistrer est aussi une solution).
Ta solution est bonne dans le fichier fonction.php mais c’est vrai que sans miniature c’est beaucoup moins intéressant. J’au comme Cyrille Sanson-Stern essayé « Svg support » dispo ici https://fr.wordpress.org/plugins/svg-support
C’est un module génial qui ajoute justement les miniatures.
Bonjour,
Une autre extension permet de gérer les SVG. https://fr.wordpress.org/plugins/svg-support/
Celle-ci a + de 50 000 installations actives à ce jour.
Suite aux évolutions de WP en 4.7+ il faut ajouter le plugin (ou le morceau de code contenu dans votre fichier de fonctions) https://wordpress.org/plugins/disable-real-mime-check/
Cf : https://core.trac.wordpress.org/ticket/39550
Perso je me servais de toutes façons de ce type de solution que temporairement et non en production. Après l’autre manière très bourrine est d’utiliser : define(‘ALLOW_UNFILTERED_UPLOADS’, true); en fichier de conf ou functions.
Bonjour. Je ne comprends rien.
Voilà.
Biz quand même
Qu’est-ce que vous ne comprenez pas ?
Nota: une petite erreur de code dans le plugins https://wordpress.org/plugins/scalable-vector-graphics-svg/, il ne gère pas le cas d’un deuxième attributs pouvant provoqué une attaque ( ligne 48 du fichier class.svg-sanitizer.php ) et également d’une deuxième balise dangereuse consécutive ( ligne 53 du fichier class.svg-sanitizer.php ) .
Il suffit de comparer le code du plugins avec le code de la librairie https://github.com/alnorris/SVG-Sanitizer.
Pourquoi cette omission? Car dans le code de la librairie https://github.com/alnorris/SVG-Sanitizer celle-ci ne tient pas compte des namespaces ( attributs souvent placer par des logiciel tel que illustrator ) du coup on se retrouve avec une erreur de max execution sous php ( ex: sodipodi:version= »0.32″ ).
Pour corrigé cela il faut ajouté après la ligne 48 du plugins: « if( $currentNode->removeAttribute($attrName) ) $x–; » et après la ligne 53 « if( $currentNode->parentNode->removeChild($currentNode) ) $i–; ».
Et vous voilà vraiment en sécurité avec les SVG.
Merci pour vos échanges de commentaires. Personnellement j’ai opté pour la solution d’Aurélein étant donné que je suis le seul admin sur ma plate-forme, mais je demeure conscient de la faille potentielle grace à Julio!
Merci les gars!
Bonjour et aïe j’ai mal.
Résumé pour ceux qui ne veulent pas lire mon pavé : ceci représente une faille de sécurité. Lisez de suite le dernier paragraphe de ce commentaire.
Explications pour ceux que ça intéresse :
Il faut commencer par se demander pourquoi WordPress n’autorise pas de base l’upload des .svg, ce magnifique format d’image vectorielles.
Car si WordPress ne le gère pas, il doit y avoir une raison, non ? La réponse est dans le code que tu as donné : « xml ».
Un SVG est un XML. Les XML sont des fichiers tout à fait lisible qu’un humain peut créer de toute pièce, il est possible de créer un SVG depuis une page blanche, bref.
Le soucis est que le XML peut contenir beaucoup de choses qui n’ont rien à voir avec les images, mais le fichier sera tout de même lu par WordPress. un exemple de faille XML est une XXE (voir https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing), ou une bombe d’entités imbriquées, ou corruption de la mémoire dan sle but de la faire déborder (overflow) etc ce qui est donc potentiellement possible dans un SVG, qui est un XML.
D’autres infos ici https://www.owasp.org/images/0/03/Mario_Heiderich_OWASP_Sweden_The_image_that_called_me.pdf
La solution est de nettoyer les XML (donc SVG) des DTD processing, XInclude, XSL, XSI et résolution.d’entités. Pour cela il existe une librairie https://github.com/alnorris/SVG-Sanitizer qui vous permet lors de l’upload de nettoyer tout ça.
Par chance un plugin qui fait tout ça existe, il gère même la miniature : https://wordpress.org/plugins/scalable-vector-graphics-svg/
Voilà, maintenant, vous êtes secure 😉
Merci pour le complément sécurité ! Je t’avoue que je comprends pas grand chose aux différents termes que tu emploies… :p
Ce qui me déplait dans tout ça c’est d’avoir besoin d’un plugin pour gérer les SVG, un jour il faudra bien que ce soit natif…
Non, le SVG est un besoin particulier qui requiert une lib si on souhaite nettoyer tout ça. Ton code est « bon » mais il faut alors être le seul admin à les envoyer après être certain qu’ils soient OK.
Si WP autorise l’upload, il nettoie ou pas ? Si « non » alors faille possible, si « oui » alors perte de données possible pour d’autres.
Nous avons donc 3 solutions aujourd’hui :
1- Ne pas avoir besoin d’uploader des SVG, cela n’empêche pas d’avoir un thème ou des plugins qui en utilisent, juste, je ne peut pas en uploader.
2- Uploader tout ce qu’on veut en SVG (ton code), mais il faut être conscient du risque et/ou limiter les comptes qui ont ce droits
3- Utiliser le plugin qui fera alors le travail de nettoyage
Non, WP ne peut pas gérer 3 cas 😉
Ta réponse clarifie mon esprit, je te remercie ! 😎
Donc si on autorise l’upload de SVG uniquement pour l’administrateur avec le code suivant ca ne devrai pas poser de problème de sécurité ?
function custom_mtypes( $m ){
if(get_current_user_id()==1){
$m[‘svg’] = ‘image/svg+xml’;
$m[‘svgz’] = ‘image/svg+xml’;
return $m;
}
}
add_filter( ‘upload_mimes’, ‘custom_mtypes’ );