Checklist de mise en ligne d’un site : 8 contrôles de sécurité avant le lancement

1. La checklist de mise en ligne en un coup d’œil

Contrôlez chaque nom public que vous servez, en général le domaine avec et sans www, en http:// comme en https://. Avant la bascule DNS, vous pouvez tester le nouveau serveur sous le vrai nom avec curl -sI --resolve example.com:443:203.0.113.10 https://example.com/, en remplaçant l’adresse d’exemple par celle du nouveau serveur.

Les huit lignes suivent les huit contrôles passifs du snapshot gratuit, qui examine une origine publique sans compte. Les vérifications manuelles ci-dessous vont plus loin qu’un passage unique sur une origine : elles couvrent chaque nom d’hôte, les deux schémas, les pages d’erreur, DKIM et les réglages chez votre bureau d’enregistrement (registrar).

2. Résolution DNS : chaque nom pointe vers le nouvel hôte

Pourquoi c’est important. Une migration partielle passe facilement inaperçue : le domaine seul est sur le nouveau serveur alors que www reste un CNAME vers l’ancienne plateforme. Les enregistrements oubliés posent aussi un problème de sécurité. La fiche OWASP sur la prise de contrôle de sous-domaines explique comment un CNAME qui pointe vers une ressource cloud supprimée peut permettre à un tiers de s’approprier le sous-domaine, et comment un enregistrement MX orphelin peut lui permettre de recevoir le courrier de ce nom, voire d’obtenir des certificats par une validation fondée sur l’e-mail.

Comment vérifier.

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Répétez les requêtes sur un résolveur public (dig @1.1.1.1 …) au cas où votre réseau garderait une réponse en cache, puis passez en revue l’export complet de la zone chez votre fournisseur DNS.

Bon résultat. Chaque nom public pointe vers l’hôte attendu, les enregistrements AAAA n’existent que si l’hôte sert réellement le site en IPv6, au moins deux serveurs de noms répondent (le minimum fixé par la RFC 1034), et chaque enregistrement a un rôle et un responsable connus.

Correction habituelle. Corrigez ou supprimez les enregistrements périmés. Quand vous arrêtez un service, suivez l’ordre que recommande l’OWASP : modifiez ou supprimez l’enregistrement DNS, attendez au moins un TTL, et seulement ensuite supprimez la ressource cloud. Avant une bascule, baissez le TTL assez tôt pour que l’ancien TTL, plus long, soit écoulé au moment du changement, et remontez-le une fois la migration stabilisée.

3. SPF, DMARC et CAA : les enregistrements qui parlent pour votre domaine

Pourquoi c’est important. N’importe qui peut mettre votre domaine dans une ligne From. SPF liste les serveurs autorisés à envoyer du courrier en son nom, DKIM signe les messages, et DMARC indique aux destinataires quoi faire quand ni SPF ni DKIM ne réussit pour un domaine aligné sur le From visible. Gmail, Yahoo et Outlook.com exigent les trois des expéditeurs en masse. CAA désigne les autorités de certification (AC) autorisées à émettre des certificats pour vos noms, et les AC publiques doivent le consulter avant toute émission.

Comment vérifier. Interrogez le domaine utilisé dans vos adresses d’expédition, en général le domaine enregistré plutôt que www :

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

Bon résultat.

• SPF : un seul enregistrement v=spf1, dans la limite de 10 termes à requête DNS fixée par la RFC 7208 (inclusions imbriquées comprises), terminé par ~all ou -all, jamais par +all.
• DMARC : un enregistrement comme v=DMARC1; p=none; rua=mailto:dmarc@example.com, pour recevoir les rapports avant de durcir la politique. La norme actuelle, la RFC 9989 (mai 2026), indique que les domaines dont les utilisateurs peuvent écrire sur des listes de diffusion ne devraient pas publier p=reject ; ceux qui le veulent malgré tout devraient d’abord rester au moins un mois en p=none, puis autant en quarantine, en comparant les rapports.
• DKIM : chaque service qui envoie pour vous signe avec votre domaine. Les clés publiques se trouvent sur selector._domainkey.example.com : il faut donc connaître chaque sélecteur pour les interroger ; il figure dans la balise s= de l’en-tête DKIM-Signature d’un message envoyé par le service.
• CAA : un enregistrement comme 0 issue "letsencrypt.org" pour chaque AC que vous utilisez, y compris celle de votre CDN. L’absence de CAA est permise, et CAA n’empêche pas une AC autorisée d’émettre un certificat à tort.

Correction habituelle. Fusionnez les enregistrements SPF en double, retirez les inclusions des services arrêtés et démarrez DMARC en p=none avec rapports. Un échec strict n’est pas forcément plus sûr : la RFC 9989 prévient qu’avec -all, un message peut être rejeté sur le résultat SPF avant même l’évaluation DMARC, alors qu’une signature DKIM alignée l’aurait fait passer, et ces rejets n’apparaissent jamais dans les rapports DMARC. Les destinataires qui ne trouvent pas d’enregistrement DMARC sur un sous-domaine remontent l’arborescence DNS jusqu’à la politique du domaine parent, et une AC utilise l’enregistrement CAA le plus proche, sur le nom concerné ou au-dessus, comme l’explique la page CAA de Let’s Encrypt. Un enregistrement _dmarc ou CAA absent sur www n’est donc pas une lacune en soi. Le guide pour vérifier SPF et DMARC détaille la lecture et la correction de ces enregistrements.

4. Certificat TLS : valide, couvrant tous vos noms, avec un renouvellement suivi

Pourquoi c’est important. Un certificat expiré ou qui ne couvre pas le nom arrête les visiteurs sur un avertissement du navigateur, et sur un hôte qui utilise HSTS, ils ne peuvent pas passer outre. Les renouvellements deviennent aussi plus fréquents : selon le vote SC081v3 du CA/Browser Forum, les certificats publics émis depuis le 15 mars 2026 sont valables 200 jours au plus, puis 100 jours à partir de mars 2027 et 47 jours à partir de mars 2029. Let’s Encrypt a cessé d’envoyer des rappels d’expiration par e-mail le 4 juin 2025.

Comment vérifier. Pour chaque nom d’hôte :

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

Lancez aussi s_client seul : la sortie doit contenir Verify return code: 0 (ok) et indiquer le protocole négocié.

Bon résultat. La chaîne se vérifie avec les certificats intermédiaires envoyés par le serveur, le certificat couvre chaque nom servi, la connexion utilise TLS 1.3 ou 1.2, le renouvellement est automatisé et la procédure d’exploitation désigne qui en est responsable. Une alerte d’expiration est en place et ne dépend pas de l’autorité de certification. L’ANSSI, dans ses recommandations de sécurité relatives à TLS, conseille de privilégier TLS 1.3, d’accepter TLS 1.2 et de ne plus utiliser SSLv2, SSLv3, TLS 1.0 ni TLS 1.1.

Correction habituelle. Automatisez le renouvellement avec ACME. Let’s Encrypt recommande ACME Renewal Information (ARI) ou un renouvellement aux deux tiers environ de la durée de vie du certificat, et prévient qu’un intervalle fixe de 60 jours ne suffira plus quand les certificats dureront 45 jours. Après une migration, confirmez que la nouvelle plateforme renouvelle bien. Une seule négociation ne montre que le protocole retenu : utilisez un outil d’analyse qui liste toutes les versions prises en charge pour confirmer que TLS 1.0 et 1.1 sont désactivés.

La façon dont le certificat, HSTS et les autres protections du navigateur s’articulent pendant une visite en HTTPS est expliquée dans le guide du certificat SSL/TLS et de HTTPS.

5. Redirection HTTPS : une étape vers HTTPS, un seul hôte canonique, puis HSTS

Pourquoi c’est important. Les anciens liens, les favoris, les scripts et les clients plus anciens demandent encore des adresses en http://. Une redirection les envoie vers HTTPS, mais, comme le souligne hstspreload.org, un attaquant placé sur le chemin réseau peut intercepter et réécrire cette redirection. HSTS comble cette faille pour chaque visite après la première visite sécurisée. L’ANSSI juge d’ailleurs nécessaire de mettre en œuvre HSTS dans ses recommandations pour la mise en œuvre d’un site web, en rappelant qu’un accès durable en HTTPS en est le prérequis.

Comment vérifier.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

Bon résultat.

• Une redirection permanente (301, ou 308 pour conserver la méthode de la requête) vers le même chemin en HTTPS sur le même hôte, comme le conseille le guide TLS de MDN, puis au plus une étape de plus vers l’hôte canonique. Le chemin et les paramètres de la requête sont conservés.
• La réponse HTTPS envoie Strict-Transport-Security. Les navigateurs ignorent cet en-tête en HTTP simple : la redirection elle-même n’a pas besoin de le porter.
• Pas de contenu mixte : les navigateurs bloquent les scripts chargés en http:// sur une page HTTPS.

Correction habituelle. Redirigez dans le serveur ou le CDN, pas en JavaScript. Relevez le max-age de HSTS par paliers jusqu’à une valeur longue comme 31536000 (un an), et n’ajoutez includeSubDomains que lorsque tous les sous-domaines servent HTTPS. hstspreload.org recommande désormais HSTS mais pas le préchargement. Si vos certificats utilisent le défi ACME HTTP-01, laissez le port 80 accessible. Pour tester ce point avec le snapshot gratuit, saisissez l’adresse en http:// ; avec un domaine saisi sans préfixe ou une adresse en https://, il vérifie à la place le max-age de HSTS et le contenu mixte.

6. En-têtes de sécurité : vérifier la réponse finale et les pages d’erreur

Pourquoi c’est important. Les en-têtes de sécurité indiquent au navigateur ce qu’une page peut charger, qui peut l’intégrer dans un cadre et comment traiter les types de contenu. Ils sont souvent définis dans la configuration d’un serveur ou d’un CDN, si bien qu’un changement d’hébergement peut les faire disparaître. Ils limitent les dégâts de failles comme le cross-site scripting ; ils ne corrigent pas les failles.

Comment vérifier.

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

Vérifiez aussi la page d’erreur : sans le paramètre always, nginx n’envoie les valeurs de add_header qu’avec certains codes de réponse, comme le note la fiche OWASP sur les en-têtes HTTP ; sous Apache, utilisez Header always set pour la même raison.

Bon résultat. Un point de départ raisonnable pour un site simple :

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• Déployez d’abord la CSP en Content-Security-Policy-Report-Only. Elle doit autoriser tout ce que vos pages chargent légitimement, et 'unsafe-inline' en annule une bonne partie de l’intérêt.
• frame-ancestors n’hérite pas de default-src et est ignoré dans une balise <meta> ; X-Frame-Options: DENY est l’ancien repli.
• Les cookies de session portent Secure, HttpOnly et un SameSite explicite (voir MDN sur Set-Cookie). HttpOnly empêche les scripts de la page de lire le cookie (par exemple via document.cookie), mais le navigateur continue de l’envoyer avec les requêtes correspondantes : il limite le vol de cookie par XSS sans empêcher la faille XSS elle-même.
• Pas d’en-tête X-XSS-Protection, ou bien réglé à 0.

Correction habituelle. Posez les en-têtes dans une seule couche (serveur, application ou CDN), pour que chaque réponse, pages d’erreur comprises, reçoive chaque en-tête exactement une fois. Le guide pour vérifier les en-têtes de sécurité HTTP détaille chaque en-tête.

7. Technologies exposées, cache et compression

Technologies exposées

Pourquoi c’est important. Server, X-Powered-By et les balises generator indiquent à tout le monde quels logiciels vous utilisez, et MDN note que des numéros de version détaillés peuvent faciliter la recherche de vulnérabilités connues. Les masquer relève de l’hygiène, pas de la protection : le guide de test de l’OWASP parle de sécurité par l’obscurité, et MDN juge plus solide de tenir les logiciels à jour.

Comment vérifier. Lancez curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):', puis cherchez dans le code source de la page la balise generator et les noms de fichiers de scripts qui contiennent un numéro de version.

Bon résultat. Server: nginx sans numéro de version, et pas de X-Powered-By.

Correction habituelle. server_tokens off; sous nginx, expose_php = Off dans php.ini, app.disable('x-powered-by') sous Express. Si une page révèle une bibliothèque obsolète, mettez-la à jour plutôt que de la cacher.

Cache, compression et CDN

Pourquoi c’est important. Les règles de cache décident qui reçoit une copie stockée d’une réponse. Une page personnalisée mise en cache par un CDN peut être servie au visiteur suivant, et c’est pourquoi MDN indique que les réponses personnalisées ont besoin de Cache-Control: private.

Comment vérifier. Lancez curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/, puis connectez-vous, ouvrez une page de compte et lisez ses en-têtes de réponse dans les outils de développement du navigateur.

Bon résultat. Le HTML est servi avec Content-Encoding: br ou gzip ; chaque réponse porte un Cache-Control explicite ; un max-age long avec immutable n’est utilisé que pour les fichiers statiques versionnés ; les pages qui contiennent des données d’utilisateur portent private ou no-store (no-cache autorise encore le stockage).

Correction habituelle. Réglez Cache-Control par type de route, gardez les chemins réservés aux utilisateurs connectés hors du cache du CDN, et compressez le texte au niveau du serveur ou du CDN. Ne pas avoir de CDN n’est pas un risque en soi ; le guide sur la performance web traite de la vitesse.

8. Enregistrement du domaine : échéance, verrou et contacts

Pourquoi c’est important. Quand un domaine sous une extension générique comme .com expire, l’Expired Registration Recovery Policy de l’ICANN oblige le bureau d’enregistrement à interrompre sa résolution DNS pendant une période : le site et la messagerie s’arrêtent en même temps. Les domaines nationaux comme .fr, .be, .ch ou .ca suivent les règles de leur propre registre ; demandez à votre bureau d’enregistrement ce qui se passe à l’échéance. Dans tous les cas, les rappels de renouvellement partent vers le contact enregistré, qui peut être un ancien salarié ou une boîte aux lettres sur le domaine même qui expire.

Comment vérifier. Utilisez l’outil de recherche de l’ICANN. Depuis le 28 janvier 2025, RDAP est la source de référence pour les données d’enregistrement des extensions génériques ; les registres et bureaux d’enregistrement de ces extensions ne sont plus tenus d’assurer un service WHOIS, sauf pour .com, .name et .post. Pour les extensions nationales comme .fr, .be, .ch ou .ca, utilisez la recherche proposée par le registre concerné ou par votre bureau d’enregistrement. Connectez-vous ensuite à votre compte chez le bureau d’enregistrement et contrôlez ses réglages.

Bon résultat.

• Échéance dans plusieurs mois, renouvellement automatique actif, et un moyen de paiement encore valable à la date de renouvellement.
• clientTransferProhibited en place, plus les verrous de modification et de suppression quand le bureau d’enregistrement les propose ; pas de clientHold ni de serverHold, qui retirent le domaine du DNS.
• Des adresses de contact lues par plus d’une personne, dont au moins une hors du domaine lui-même, et une authentification à deux facteurs sur le compte du bureau d’enregistrement.

Correction habituelle. Activez le renouvellement automatique, renouvelez pour plusieurs années, demandez au bureau d’enregistrement de poser les statuts de verrouillage (le guide des codes de statut EPP de l’ICANN explique chacun d’eux) et mettez les contacts à jour.

9. Ce que cette checklist ne couvre pas

Ces huit points décrivent la configuration publique autour de votre site. Un site peut les réussir tous et rester facile à compromettre, car aucun ne regarde l’application ni la façon dont elle est exploitée. Examinez séparément :

• Les vulnérabilités applicatives : injections, cross-site scripting dans vos gabarits, envois de fichiers non sécurisés, accès aux données d’autres comptes.
• L’authentification et les sessions : connexion, réinitialisation du mot de passe, double authentification, interfaces d’administration.
• Les dépendances et les serveurs : extensions du CMS, paquets, correctifs du système d’exploitation.
• Les secrets et les accès : clés dans les dépôts de code ou dans le JavaScript livré au navigateur, et qui peut accéder à la production, au fournisseur DNS et au bureau d’enregistrement.
• Les sauvegardes : une restauration réellement testée.

Le guide pour tester la sécurité d’un site web passe en revue la connexion, les permissions et d’autres contrôles côté application, et l’OWASP Web Security Testing Guide fournit des cas de test détaillés.

Un premier passage rapide sur une origine. Le snapshot gratuit ne demande pas de compte. Pour une origine publique, il lit le DNS public, les enregistrements DNS de messagerie, les données d’enregistrement du domaine, la négociation TLS et la réponse HTTP de la page d’accueil, sans envoyer d’exploit, de scan de ports, de tentative de connexion ni de charge. Vous obtenez un score, une note de durcissement, le nombre de signaux de risque et de contrôles réussis, et jusqu’à trois signaux à examiner en premier. Ce n’est pas un test d’intrusion : un bon score signifie que ces signaux publics paraissaient sains à ce moment-là. L’offre Free couvre uniquement les contrôles de sécurité ; les six domaines d’audit (sécurité, SEO technique, visibilité IA, accessibilité, performance, intégrations) sont disponibles à partir de 49 $ US par mois avec l’offre Starter.