Lors d’un audit de sécurité, certains points « classiques » peuvent être remontés.
Cela ne signifie pas forcément que votre site est en danger ou mal conçu.
Cet article a pour objectif de vous expliquer, de manière simple :
- pourquoi ces points sont signalés,
- quel est leur impact réel,
- et pourquoi, dans certains cas, ils ne peuvent pas être modifiés sans risque.
1. Ports et interfaces accessibles sur le serveur
Ce que signalent les audits
Les outils d’audit détectent plusieurs ports ouverts (points d’entrée réseau), par exemple :
- FTP (21), HTTP (80), HTTPS (443)
- services de messagerie (25, 110, 143, 465, 993, 995)
- interfaces comme cPanel ou le webmail (2083, 2087, 2096)
Ces éléments sont souvent listés comme des « surfaces d’attaque potentielles ».
Pourquoi ces ports sont ouverts
Ces ports sont indispensables au fonctionnement normal du site :
- affichage du site web,
- envoi et réception d’e-mails si vous disposez d’un service mail sur cette infrastructure,
- administration technique du serveur.
Ils font partie de l’infrastructure standard de l’hébergeur (un environnement virtualisé dans la plupart des cas).
Pourquoi on ne peut pas les fermer
Ces ports :
- sont connus et maîtrisés,
- sont protégés par des mécanismes de sécurité (chiffrement, anti brute-force),
- ne peuvent pas être modifiés individuellement sans impacter le service.
👉 Leur présence est normale et ne constitue pas une faille en soi.
👉 Si vous disposez d’un service mail sur cette infrastructure il est indispensable d’utiliser les ports cryptés 465, 993 et 995.
2. Accès à la base de données à distance
Ce que signalent les audits
La présence d’un accès distant à la base de données (MySQL sur le port 3306) peut être signalée comme un risque potentiel.
Pourquoi cet accès existe
Il est utilisé pour :
- l’exploitation technique,
- certaines opérations de maintenance ou de supervision.
Quelles protections sont en place
Cet accès est sécurisé par :
- des protections contre les attaques par force brute,
- des identifiants non publics,
- des mises à jour régulières de l’hébergeur.
👉 En pratique, l’accès est contrôlé et surveillé.
3. Failles XSS (injection de scripts)
Ce que signalent les audits
Sur certains sites, principalement anciens, des audits remontent des failles XSS, souvent liées à des champs de recherche ou des formulaires.
Pourquoi cela arrive
Ces failles apparaissent surtout sur :
- des sites développés il y a plusieurs années,
- des fonctionnalités où les données utilisateur n’étaient pas systématiquement filtrées.
Comment c’est traité
Les corrections consistent généralement à :
- filtrer et sécuriser les données saisies par les utilisateurs avant leur affichage.
👉 Sur les sites récents, ces bonnes pratiques sont déjà intégrées.
👉 Sur les sites plus anciens, des corrections ciblées peuvent être nécessaires, nous transmettre les informations remontées par l’audit.
4. Sécurité liée aux en-têtes HTTP (headers)
Ce que signalent les audits
Les audits vérifient la présence de certains headers de sécurité, par exemple :
- protection contre le clickjacking,
- sécurisation des cookies (secure, httponly),
- politiques de chargement des scripts (CSP),
- autres headers de sécurité (HSTS, X-Frame-Options, Referer, X-Content-Type-Options)
Ce qui est déjà en place
Nos projets récents intègrent une configuration optimisée qui couvre ces points dès la phase de développement.
Pour les sites plus anciens, une mise à jour de la configuration peut être nécessaire.
Pourquoi certaines règles sont volontairement souples
Certains audits indiquent que la politique CSP est « trop permissive ».
C’est un choix volontaire :
- pour garantir le bon fonctionnement des fonctionnalités, spécifiquement avec l’architecture de WordPress,
- pour éviter de bloquer des plugins ou des scripts nécessaires.
👉 Une politique trop restrictive peut casser le site.
👉 Des améliorations progressives sont prévues, avec des tests pour garantir la compatibilité.
5. Sécurité SSL / TLS (HTTPS)
Ce que signalent les audits
Les audits peuvent mentionner :
- des algorithmes (cypher suites) jugés « faibles »,
- des attaques théoriques (Lucky13, BREACH).
Quelle est la réalité du risque
- La redirection HTTPS est déjà en place.
- Les attaques mentionnées sont très théoriques et nécessitent des conditions spécifiques, certaines sont remontées par des audit en faux-positif car correctement couvertes au niveau de l’infrastructure.
- Les sites reposent sur des mécanismes modernes (tokens, protections intégrées à WordPress).
Les paramètres SSL dépendent en grande partie de l’infrastructure de l’hébergeur et ne peuvent pas être ajustés site par site.
👉 Les tests réalisés montrent un excellent niveau de sécurité global.
6. Sécurité des e-mails (SPF, DKIM, DMARC)
Ce que signalent les audits
Les audits vérifient la présence de règles permettant d’éviter :
- l’usurpation d’identité,
- l’envoi de mails frauduleux depuis votre domaine.
Comment c’est géré
- Lorsque nous gérons la messagerie, ces règles sont mises en place systématiquement.
- Lorsque la messagerie est gérée par un tiers, nous appliquons les paramètres fournis par ce service lorsque nous gérons pour vous le nom de domaine concerné.
👉 Ces réglages sont essentiels pour la délivrabilité et la sécurité des e-mails.
7. Librairies JavaScript obsolètes (ex. jQuery)
Ce que signalent les audits
Les audits de sécurité détectent parfois l’utilisation de librairies JavaScript anciennes, en particulier jQuery, et recommandent leur mise à jour en raison de vulnérabilités connues dans certaines versions.
Pourquoi ces versions sont encore utilisées
Sur certains sites, notamment les plus anciens :
- des fonctionnalités spécifiques,
- des plugins WordPress,
- ou des développements sur mesure
dépendent d’une version précise de jQuery.
Une mise à jour directe et non maîtrisée peut provoquer des régressions fonctionnelles (boutons qui ne répondent plus, formulaires cassés, affichage incorrect).
Quel est le risque réel
Dans la majorité des cas :
- les failles identifiées sont conditionnelles,
- elles nécessitent une exploitation active et un contexte précis,
- elles ne sont pas directement exploitables sans autre faiblesse sur le site.
👉 Le risque reste donc limité tant que le site est à jour par ailleurs et correctement configuré.
Comment nous traitons ce sujet
Lorsqu’une mise à jour est demandée :
- nous analysons les dépendances du site,
- nous testons la compatibilité des fonctionnalités et des plugins,
- nous procédons à une mise à jour progressive et sécurisée.
Sur les sites récents, les versions de jQuery utilisées sont déjà conformes aux recommandations actuelles.
Pourquoi cela peut nécessiter une intervention spécifique
Contrairement à une simple configuration serveur, la mise à jour d’une librairie JavaScript :
- implique du temps de développement et de tests,
- nécessite parfois des adaptations de code,
- ne peut pas être automatisée sans risque.
👉 C’est pourquoi ce point peut faire l’objet d’une intervention dédiée, afin de garantir à la fois la sécurité et la stabilité du site.
En résumé
- Beaucoup de points signalés par les audits sont informatifs et non bloquants.
- Certains éléments sont liés à l’infrastructure de l’hébergeur et ne peuvent pas être modifiés individuellement.
- Les sites récents intègrent déjà les meilleures pratiques de sécurité.
- Pour les sites plus anciens, des améliorations ciblées peuvent être envisagées si nécessaire.
Notre objectif est toujours de trouver le bon équilibre entre sécurité, stabilité et bon fonctionnement du site.
