# Analyse de sécurité de site web en moins d'une minute.

Analyse de sécurité de site web pour les petites entreprises. Vérifiez HTTPS, les en-têtes de sécurité, les e-mails et les traceurs, puis téléchargez un PDF avec les corrections.

## Que vérifie une analyse de sécurité de site web ?

L'analyse effectue 28 vérifications sur votre page d'accueil. Elle couvre HTTPS et les redirections, les en-têtes de sécurité, les cookies, les enregistrements e-mail et DNS, les scripts tiers, les traceurs et les bibliothèques obsolètes. Chaque résultat indique quoi corriger, quoi examiner et ce que nous n'avons pas pu vérifier.

### Connexion HTTPS

Le site répond-il de manière chiffrée et demande-t-il aux navigateurs de conserver HTTPS ?

### Protection du navigateur

Le site peut-il bloquer les scripts indésirables, empêcher d'autres sites de l'intégrer et empêcher les navigateurs de deviner les types de fichiers ?

### Cookies, traceurs et logiciels

Nous vérifions les cookies, les traceurs qui se chargent avant l'accord des visiteurs, les bibliothèques JavaScript obsolètes et les versions de logiciels que le site dévoile.

## Tirez davantage de votre analyse de sécurité de site web

### Ce que révèle une analyse de sécurité de site web

Une analyse de sécurité de site web montre les paramètres que votre page d'accueil envoie à chaque visiteur. Nous vérifions HTTPS, les en-têtes de sécurité, les cookies, les e-mails, les traceurs et les logiciels que le site dévoile. Utilisez votre analyse de sécurité de site web pour préparer des questions pour votre développeur et garder une trace datée avant tout changement.

### Comprendre votre analyse de sécurité de site web

Votre analyse de sécurité de site web classe les résultats en vérifications urgentes pour l'hébergeur, paramètres à corriger et choix qui dépendent de votre site. Un en-tête facultatif manquant n'est pas le signe d'une attaque. Le score d'une analyse de sécurité de site web va de 0 à 100 et compte les vérifications réussies. Les couleurs indiquent quoi regarder en premier.

### Avant et après une analyse de sécurité de site web

Lancez une analyse de sécurité de site web avant de changer d'hébergement ou de paramètres de sécurité, pour avoir un point de comparaison. Vérifiez les pages de paiement, les connexions et les services intégrés avant de durcir les règles. Ensuite, lancez une nouvelle analyse de sécurité de site web, comparez-la à l'ancien rapport et testez le site dans un vrai navigateur. Gardez les mises à jour et la sécurité des comptes dans votre maintenance habituelle.

### Partager une analyse de sécurité de site web avec votre développeur

Une analyse de sécurité de site web est plus facile à appliquer quand la personne qui fait le travail peut la voir. Téléchargez le PDF ou envoyez le lien du rapport à votre développeur. Chaque analyse de sécurité de site web indique quand elle a été faite. Le propriétaire du site peut aussi publier le rapport après avoir prouvé qu'il contrôle le site.

## Questions sur la sécurité de votre site

### Une analyse de sécurité de site web prouve-t-elle que mon site est sûr ?

Non. Elle vérifie une sélection de paramètres publics. Elle ne peut pas trouver toutes les vulnérabilités, logiciels malveillants, erreurs de code ou comptes piratés. Un audit de sécurité complet va beaucoup plus loin.

### Une analyse de sécurité de site web affecte-t-elle mon site ?

À peine. L'analyse consulte vos enregistrements DNS, demande la page d'accueil en HTTPS et en HTTP simple, suit jusqu'à cinq redirections, lit security.txt et charge la page d'accueil une fois dans un navigateur cloud. Elle ne visite pas d'autres pages, n'envoie aucun formulaire, ne se connecte pas et ne tente aucune attaque. Si votre site bloque l'analyse, le résultat est incomplet.

### Pourquoi limiter l’analyse de sécurité de site web à deux contrôles par jour ?

La limite permet de garder l'outil gratuit et d'éviter un trafic inutile vers les sites.

### Que signifient les couleurs de l’analyse de sécurité de site web ?

Rouge signifie que votre hébergeur doit vérifier quelque chose en urgence, comme une ancienne version de PHP avec une faille critique connue. Orange signifie qu'un paramètre est à corriger. Bleu signifie qu'un examen plus attentif vaut la peine. Vert signifie que la vérification est réussie. Gris signifie que nous n'avons pas pu vérifier. Aucune de ces couleurs ne signifie que votre site a été piraté.

### Une analyse de sécurité de site web détecte-t-elle PHP2Shell ?

Elle peut signaler une version de PHP plus ancienne que les versions corrigées. Les en-têtes de version peuvent être faux, masqués ou modifiés, et certains hébergeurs corrigent d'anciennes versions. Demandez à votre hébergeur de confirmer la version de PHP installée et ses correctifs. Nous n'envoyons jamais de requêtes d'attaque. Un en-tête PHP absent ne signifie pas que PHP est absent ou corrigé.

### Pourquoi l’analyse de sécurité de site web signale-t-elle les en-têtes logiciels ?

Les numéros de version facilitent la recherche de sites qui utilisent un logiciel vulnérable. Supprimez-les quand c'est possible. Les masquer ne corrige rien, alors gardez le logiciel lui-même à jour.

### Que faire après une analyse de sécurité de site web ?

Commencez par les points rouges, puis passez en revue les points orange avec votre développeur ou votre hébergeur. Testez les changements d'en-têtes avant la mise en ligne, car des règles strictes peuvent casser les paiements, les formulaires et les contenus intégrés. Téléchargez le PDF pour partager les résultats. Mecanik Dev peut vous aider à choisir les bonnes corrections et à les mettre en place.

### Les résultats de mon analyse de sécurité de site web sont-ils publics ?

Non. Les analyses sont privées. Seul le propriétaire d'un site peut publier son rapport, après avoir prouvé qu'il contrôle le site avec un enregistrement DNS ou un fichier. Vous pouvez toujours partager un lien privé ou le PDF. Aucun compte ni e-mail n'est nécessaire.

## Les contrôles de votre rapport

### Connexion chiffrée

HTTPS chiffre les données entre le site et ses visiteurs. Cela montre que le scanner s'est connecté de façon sécurisée. Le reste du site n'est pas testé.

### Rediriger le HTTP simple vers HTTPS

Les visiteurs qui tapent l'adresse sans https:// doivent arriver directement sur le site sécurisé. HSTS garde ensuite leur navigateur sur HTTPS.

### Maintenir les visiteurs sur HTTPS

Définissez Strict-Transport-Security avec un max-age d'au moins six mois. Vérifiez vos sous-domaines avant d'ajouter includeSubDomains ou preload.

### Contrôler les contenus exécutables

Content-Security-Policy contrôle les scripts et contenus que la page peut charger. Les bonnes règles dépendent du site, et une politique absente n'est pas une vulnérabilité en soi. Si la page définit la politique dans son HTML, la vérification dans le navigateur la lit. Les politiques en mode report-only ne bloquent rien.

### Empêcher les intégrations trompeuses

Utilisez CSP frame-ancestors ou X-Frame-Options, et n'autorisez que les sites qui ont vraiment besoin d'intégrer le vôtre.

### Éviter la détection hasardeuse des types

Réglez X-Content-Type-Options sur nosniff pour que les navigateurs traitent chaque fichier selon le type indiqué par le serveur.

### Limiter les informations transmises

Une Referrer-Policy explicite rend le comportement clair. Les navigateurs modernes limitent déjà cela par défaut, un en-tête absent ne veut donc pas dire que des données fuient.

### Limiter les fonctions sensibles

Permissions-Policy peut désactiver la caméra, le micro et la localisation pour votre site. Les bons réglages dépendent de ce que fait le site.

### Informations X-Powered-By

Supprimez les informations d'exécution quand c'est possible. Le site est alors plus difficile à identifier, mais il faut toujours le tenir à jour.

### Version du serveur exposée

Demandez à votre hébergeur de masquer les numéros de version et de garder le serveur à jour. Un nom de serveur sans version ne pose pas de problème.

### Correctifs PHP

PHP2Shell est le nom de deux failles critiques de PHP lui-même. L'en-tête n'indique qu'une version, qui peut être fausse ou ne pas montrer les correctifs appliqués par votre hébergeur. Demandez-lui de comparer la version installée aux avis de sécurité PHP actuels. Masquer l'en-tête ne corrige rien.

### Cookies limités à HTTPS

Secure signifie que le cookie n'est envoyé qu'en HTTPS. Nous ne voyons que les cookies de la réponse de la page d'accueil. Les cookies déposés après connexion ou par des scripts ne sont pas couverts, et les valeurs des cookies n'apparaissent jamais dans votre rapport.

### Protection des cookies de session

HttpOnly empêche les scripts de la page de lire le cookie. Nous devinons les cookies de session d'après leur nom, demandez donc à votre développeur de confirmer.

### Règles des cookies intersites

SameSite contrôle quand les cookies sont envoyés avec des requêtes venant d'autres sites. None peut convenir à certaines intégrations, et les navigateurs appliquent une valeur par défaut s'il manque.

### Accès entre origines

CORS est souvent nécessaire pour les API et les fichiers partagés. Un joker seul n'expose pas de données privées. Cette vérification de la page d'accueil ne peut pas savoir si une API fait confiance à n'importe quelle origine.

### Isolation des fenêtres

COOP isole la page des fenêtres ouvertes par d'autres sites. Les fenêtres de paiement et de connexion peuvent demander un réglage plus souple. Son absence ne rend pas le site vulnérable à elle seule.

### Intégration des ressources

Cross-Origin-Resource-Policy contrôle quels sites peuvent intégrer vos fichiers. Les images publiques et les fichiers partagés doivent parfois rester ouverts. La plupart des pages n'en ont pas besoin.

### Politique d'expéditeur e-mail (SPF)

SPF aide les serveurs de messagerie à rejeter les faux e-mails envoyés au nom de votre domaine. Si le domaine n'envoie jamais d'e-mails, publiez v=spf1 -all. Nous vérifions le domaine principal.

### Politique contre l'usurpation d'e-mail (DMARC)

DMARC indique aux serveurs de messagerie quoi faire des e-mails qui échouent à SPF et DKIM. Commencez en mode surveillance, lisez les rapports, puis passez à quarantine ou reject.

### Règles des autorités de certification (CAA)

Les enregistrements CAA listent les autorités de certification autorisées pour le domaine. Ils réduisent le risque qu'un certificat soit émis par erreur. Incluez chaque fournisseur que vous utilisez.

### DNS signé (DNSSEC)

DNSSEC permet aux résolveurs de repérer les fausses réponses DNS. Activez-le en même temps chez votre fournisseur DNS et votre registraire, car une mauvaise configuration peut rendre le domaine inaccessible.

### Contact sécurité (security.txt)

Publiez /.well-known/security.txt avec Contact et Expires, pour que les personnes qui trouvent un problème sachent comment vous joindre.

### Ressources de page non sécurisées

Les fichiers non sécurisés peuvent être modifiés en chemin, et les navigateurs peuvent les bloquer et casser la page. Passez ces adresses en HTTPS. Nous n'avons vérifié que la page d'accueil.

### Services tiers

Chaque script ou service externe peut voir vos visiteurs et modifier la page. Gardez une liste courte, retirez ce que vous n'utilisez plus et vérifiez ce que reçoit chaque fournisseur. Utiliser des services externes n'est pas une vulnérabilité en soi.

### Suivi avant consentement

Des lois comme le RGPD exigent en général un consentement avant tout suivi non essentiel. Le scanner charge la page une fois depuis nos serveurs et n'accepte rien. Les outils de consentement peuvent réagir différemment selon le pays, vérifiez donc aussi votre propre configuration.

### Bibliothèques JavaScript obsolètes

Nous reconnaissons jQuery, jQuery UI, Bootstrap, AngularJS, Lodash et Moment.js quand ils affichent leur version. Mettez à jour la bibliothèque concernée, ou le thème ou l'extension qui l'inclut, puis testez le site.

### Contrôles d'intégrité des scripts

Subresource Integrity permet aux navigateurs de refuser une copie modifiée d'un fichier script. Cela fonctionne pour les fichiers versionnés d'un CDN. Cela ne convient pas aux scripts qui changent volontairement, comme les gestionnaires de balises.

### Version de la plateforme du site

Une balise generator avec un numéro de version rend le site plus facile à cibler par des attaques automatisées. Supprimez-la quand c'est possible et gardez à jour la plateforme, les thèmes et les extensions. Masquer la version ne corrige rien.

## Avis de confidentialité

Pour empêcher les abus et répondre aux réclamations ou aux demandes légales, Mecanik Dev Ltd conserve une trace de chaque analyse. Elle contient le site web, l'heure, la version de la notice, votre adresse IP, les détails de votre navigateur et de votre appareil, et votre position approximative déduite de votre adresse IP. Nous conservons ces données 30 jours, puis nous les supprimons. Nous ne les utilisons pas à des fins de marketing et ne les partageons que si la loi l'exige.

Notre hébergeur et prestataire de sécurité traite votre adresse IP pour faire fonctionner le service et la vérification anti-bot, et conserve ses propres journaux. Accepter une analyse ne veut pas dire accepter la prospection. Votre navigateur crée lui-même le PDF.

Consultez notre politique de confidentialité principale pour les coordonnées du responsable, vos droits et les informations sur les prestataires.

Si vous publiez un rapport, nous conservons le domaine, l'heure de l'analyse et les résultats pendant 90 jours au plus. L'annuaire public montre le dernier rapport de chaque site. Les analyses privées n'y sont jamais enregistrées. Les rapports publics plus anciens restent en ligne jusqu'à leur expiration ou leur suppression. Les rapports publics ne contiennent jamais les adresses IP, les informations de navigateur, les autorisations ou les valeurs de cookies des visiteurs.

Le thème est enregistré dans ce navigateur. Le rapport actuel reste dans le stockage de session de cet onglet pour changer de langue sans nouvelle analyse. Effacez le stockage du navigateur pour supprimer ces préférences et résultats.