Audit sécurité site web 2026 : la checklist complète des 10 dimensions à vérifier

Pourquoi auditer la sécurité d'un site web en 2026

Le paysage de la sécurité web a profondément changé entre 2020 et 2026. La CNIL a multiplié par trois le nombre de sanctions pour défaut de sécurité depuis 2023, atteignant un record de 89 millions d'euros d'amendes cumulées au titre de l'article 32 du RGPD (« sécurité du traitement ») sur l'année 2025. L'European Accessibility Act(EAA), entré en vigueur en juin 2025, a élargi la responsabilité légale des éditeurs sur la couche transport (TLS) et l'intégrité des contenus servis. Et les attaques sur lasupply chain JavaScript (event-stream, polyfill.io, ua-parser-js) ont rendu obsolète l'idée qu'on pouvait charger une dépendance tierce sans contrôle d'intégrité.

Pour une agence web ou un freelance, la question « est-ce que mon site est sécurisé ? » revient toutes les semaines de la part des clients. Et les deux réponses traditionnelles ne tiennent plus : SecurityHeaders.comne teste qu'une dimension (les headers) et fait peur au client avec un grade en anglais ; un pentest cabinetà 3 000-8 000 € est hors-budget pour 80 % des sites vitrines et e-commerce de moins de 50 k€/an de CA. Cet article propose un cadre intermédiaire : 10 dimensions à auditer méthodiquement, des exemples concrets vus sur des audits réels, et les correctifs actionnables qui se déploient en moins de 30 minutes.

La méthodologie suivante est celle que nous appliquons dans le produit SecAudit. Elle synthétise les recommandations de l'ANSSI (guide « Recommandations pour la sécurisation des sites web »), de l'OWASP (Top 10 2021 + ASVS 4.0), de la CNIL (référentiel sécurité du traitement) et du NIST (SP 800-53 contrôles AC, IA, SC).

1. Headers de sécurité HTTP

Les headers de sécurité sont la première ligne de défense côté navigateur. Ils ne demandent aucune modification applicative et se déploient en quelques minutes côté reverse proxy ou CDN. Voici les six headers à auditer en priorité :

• Content-Security-Policy (CSP) : restreint les origines autorisées pour le JS, CSS, images, frames. Une CSP stricte (ex. default-src 'self'; script-src 'self' cdn.example.com) bloque la majorité des injections XSS.
• Strict-Transport-Security (HSTS) : force le navigateur à n'utiliser que HTTPS pour le domaine. Recommandation 2026 : max-age=63072000; includeSubDomains; preload + soumission au HSTS preload list.
• X-Frame-Options : DENY ou SAMEORIGIN empêche le clickjacking par iframe-embedding.
• X-Content-Type-Options : nosniff bloque le MIME-sniffing du navigateur.
• Referrer-Policy : strict-origin-when-cross-origin évite les fuites de chemin dans le Referer.
• Permissions-Policy : déclare explicitement quelles APIs sensibles (caméra, micro, géoloc) sont autorisées. Par défaut, désactiver tout : geolocation=(), camera=(), microphone=().

Le scoring SecAudit pondère CSP à 30 %, HSTS à 20 %, X-Frame à 10 %, le reste à 4-8 %. Un site bien configuré atteint 90/100. Sur les audits que nous avons réalisés, la médiane est à 45/100, et 54 % des sites n'ont aucun HSTS.

2. TLS / SSL — protocole, cipher, certificat

La couche transport est le socle de toute sécurité web. En 2026, quatre points font la différence entre un audit qui passe et un audit qui échoue :

• Protocole minimum TLS 1.2, idéalement TLS 1.3 supporté. SSLv3, TLS 1.0 et TLS 1.1 doivent être désactivés (deprecated par le RFC 8996 depuis 2021).
• Cipher suites modernes uniquement : AEAD-GCM ou ChaCha20-Poly1305. Bannir CBC, RC4, 3DES. Mozilla SSL Configuration Generator (profil « intermediate ») est la référence à copier-coller.
• Certificat valide : émis par une CA reconnue, non expiré, chaîne complète (intermédiaire fourni par le serveur), domaine couvert (CN ou SAN). Vérification supplémentaire : le certificat doit être renouvelé au moins 30 jours avant expiration (Let's Encrypt force 90 jours, mais des CA EV peuvent être à 1 an).
• HSTS preload + OCSP stapling activés. L'OCSP stapling évite que chaque visiteur fasse un round-trip vers la CA pour vérifier la révocation, gain perf + privacy.

SecAudit utilise tls.connect natif Node 22 et getPeerCertificate(true) pour récupérer la chaîne complète, parser validTo, vérifier le protocole et le cipher choisi. Pour HSTS preload, on interroge l'API officielle hstspreload.org/api/v2/status qui répond en moins de 200 ms.

Erreur fréquente sur 2026 : sites qui forcent TLS 1.3 mais gardent un cipher CBC en fallback pour de vieux clients. Cela dégrade le grade SSLLabs et expose à des attaques de downgrade type Lucky13 / POODLE-bis.

3. DNS — SPF, DMARC, DKIM, CAA, DNSSEC

La couche DNS est presque toujours sous-auditée parce qu'invisible côté navigateur. Pourtant, c'est elle qui détermine si vos emails sont spoofables, si une CA peut émettre un certificat pour votre domaine sans votre accord, et si un attaquant peut empoisonner votre résolution.

SPF — Sender Policy Framework

Record TXT à la racine déclarant quels serveurs SMTP sont autorisés à envoyer du mail pour le domaine. Format : v=spf1 include:_spf.google.com -all. Le terminateur -all (strict) est crucial : +all ou ?all autorisent tout serveur au monde à spoofer le domaine.

DMARC — Domain-based Message Authentication

Record TXT sur _dmarc.<domaine> qui aligne SPF + DKIM et déclare la politique en cas d'échec. Politique recommandée 2026 : v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@…. Sur 100 sites audités début mai 2026, 83 % n'ont aucun DMARC ou sont en p=none (mode passif inutile).

DKIM — DomainKeys Identified Mail

Signature cryptographique des emails sortants. Vérifié via <selector>._domainkey.<domaine>. Le selector est défini par votre fournisseur SMTP (ex. google._domainkey pour Gmail Workspace). Au moins une clé RSA 2048 bits ou Ed25519.

CAA — Certification Authority Authorization

Record CAA déclarant quelles CA peuvent émettre des certificats pour le domaine. Exemple : 0 issue "letsencrypt.org". Empêche qu'une CA compromise ou un attaquant ayant pris le contrôle d'un compte registrar émette un certificat à votre insu.

DNSSEC

Signature cryptographique de la zone DNS. Vérification via dig +dnssec. Encore peu déployé en France (≈ 7 % des domaines .fr en 2025 selon l'AFNIC). Activez-le quand votre registrar le supporte (OVH le permet via l'interface manager).

Sub-domain takeover

CNAME orphelins pointant vers Heroku, S3, Vercel, Github Pages… non revendiqués. SecAudit teste les signatures de takeover connues (NoSuchBucket, "There's no Heroku app", etc.) sur tous les sous-domaines découverts.

4. Cookies — Secure, HttpOnly, SameSite

Trois flags à exiger sur tous les cookies de session :

• Secure : cookie envoyé uniquement sur HTTPS. Combiné avec un HSTS strict, blinde le risque de fuite en clair.
• HttpOnly : interdit l'accès depuis JavaScript (document.cookie). Une XSS ne peut alors pas voler la session, ce qui réduit drastiquement l'impact.
• SameSite : Lax par défaut depuis Chrome 80 (2020). Pour les cookies de session, préférer Strict. Pour les contextes embarqués (iframe cross-origin), None; Secure est obligatoire.

SecAudit parse chaque header Set-Cookie de la réponse et flagge tout cookie de session sans les trois flags. Sur le panel d'audits, 37 % des sites ont au moins un cookie session sans HttpOnly (typiquement WordPress vieux ou frameworks PHP custom).

5. CORS — Cross-Origin Resource Sharing

CORS est un mécanisme parfaitement compris du navigateur, mais une source d'erreur récurrente côté serveur. Les deux configurations dangereuses :

• Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true. La spec interdit la combinaison, mais des frameworks legacy (vieux Express avec cors() mal configuré, WordPress REST API custom) la servent quand même. Le navigateur DEVRAIT bloquer, mais certains User-Agents anciens ne le font pas.
• Access-Control-Allow-Origin qui reflète aveuglément le header Origin: entrant. Équivaut à un wildcard. SecAudit replay une GET avec Origin: https://evil.example et flag si la valeur est renvoyée à l'identique.

Bonnes pratiques :

• Whitelister explicitement les origins autorisées dans la config CORS.
• Distinguer les endpoints publics (peuvent accepter * sans credentials) des endpoints authentifiés (whitelist stricte obligatoire).
• Limiter Access-Control-Allow-Methods aux verbes réellement utilisés (GET, POST, PATCH si REST).
• Mettre un Access-Control-Max-Age: 600 minimum pour réduire le bruit preflight.

Sur 100 audits, 3 sites servaient la combinaison interdite * + credentials. Faible volume mais impact maximum (CSRF authentifié possible depuis n'importe quel domaine attaquant).

6. Fichiers exposés — wordlist 60 paths

Cette dimension détecte les fichiers de configuration, sauvegardes et endpoints d'administration servis publiquement par le serveur web. C'est la dimension la plus impactante en cas de hit : un .env exposé donne souvent les clés du royaume (DB password, Stripe secret, JWT secret, AWS access key).

SecAudit teste 60 paths en parallèle (HEAD + GET sélectif), avec rate-limit 5/s pour rester poli :

• Config : .env, .env.local, .env.production, config.php.bak, wp-config.php~
• VCS : .git/config, .git/HEAD, .svn/entries, .hg/store/00manifest.i
• Backup : /backup/, /backup.sql, /dump.sql, /site.tar.gz, /db.sqlite
• Admin : /admin/, /wp-admin/, /administrator/, /phpmyadmin/, /adminer.php
• Debug : /phpinfo.php, /info.php, /test.php, /server-status, /server-info
• WP-specific : /xmlrpc.php, /wp-json/wp/v2/users, /?author=1
• Standards manquants : /.well-known/security.txt, /robots.txt, /humans.txt

Sur 100 audits, 12 sites servaient un .env en 200, 5 servaient /server-status Apache, 23 exposaient /wp-json/wp/v2/users avec énumération des comptes. Aucun ne servait /.well-known/security.txt (recommandé par RFC 9116).

Fix universel : location ~ /\.env { deny all; return 404; } en nginx, équivalent RedirectMatch 404 en Apache. Pour /wp-json/wp/v2/users, ajouter un filter WordPress qui restreint l'endpoint aux utilisateurs authentifiés.

7. Tech detection + lookup CVE

Identifier la stack technique d'un site (CMS, framework, version) permet ensuite de croiser avec la base NVD (National Vulnerability Database, ~220 000 CVE) pour identifier les vulnérabilités connues affectant cette version précise.

SecAudit détecte la stack via une approche rules-based, sans dépendance externe type Wappalyzer :

• Headers HTTP : X-Powered-By: PHP/7.4.33, Server: nginx/1.18.0 (Ubuntu), X-Generator: Drupal 9
• Meta generator : <meta name="generator" content="WordPress 5.7.0">
• Signatures URL : /wp-content/, /_next/static/, /sites/all/themes/
• JS globals : présence de window.Shopify, window.__NEXT_DATA__, etc. dans le HTML servi.

Une fois la stack détectée (ex. WordPress 5.7.0), SecAudit effectue un lookup contre cve_index (table Postgres avec ~220 000 CVE ingérés mensuellement depuis les feeds NVD JSON 1.1) avec semver matching contre la version_constraint (<= 5.7.2, >= 4.0 < 4.5).

Exemple concret : WordPress 5.7.0 → CVE-2021-29447, attaque XML XXE via la media library, score CVSS 9.9. Patch disponible depuis le 14 avril 2021. Sur 100 sites WP audités en 2026, 41 % tournent encore sur une version 5.x avec au moins une CVE de score ≥ 7.

Limitation importante : le matching est imparfait. SecAudit tag chaque finding CVE avec matchConfidence: low/medium/high et n'élève jamais une CVE en Critical automatique sans confirmation manuelle. Lien direct vers la page NVD sur chaque finding pour vérification.

8. OWASP basics — XSS, SQLi, CSRF, rate-limit

Cette dimension est opt-in obligatoire dans SecAudit, parce qu'elle implique l'envoi de payloads actifs (même non-destructifs) sur le site cible. En droit français, l'article 323-1 du Code pénal (équivalent du CFAA américain) sanctionne tout accès ou maintien dans un système informatique sans autorisation. Avant d'activer ce module, l'utilisateur doit cocher une attestation de propriété ou d'autorisation, et nous loggons IP + user + timestamp.

Tests réalisés (payloads non-destructifs uniquement) :

• XSS reflected : injection de <svg/onload=alert(1)> dans les paramètres GET de toutes les URLs découvertes. Si le payload est réfléchi sans échappement dans la réponse HTML, finding High.
• SQL injection error patterns : ajout d'une quote ' dans les paramètres et grep sur les erreurs typiques (You have an error in your SQL syntax, ORA-01756, PostgreSQL query failed). Pas d'UNION SELECT ni de blind SQLi (trop intrusif).
• CSRF token check : sur chaque formulaire POST découvert, vérifier la présence d'un input token (nom contenant csrf, token, nonce, _token). Absence = finding Medium.
• Rate-limit /login : 10 POST en burst sur l'endpoint de login (avec login + password aléatoires évidemment invalides). Si pas de 429 / 503 après le 5e essai, finding Medium.

Le module OWASP est désactivé par défaut sur le free tool public et n'est jamais activé sans autorisation explicite côté agence. Pour des tests profonds (Top 10 OWASP complet, business logic, auth bypass), nous recommandons un pentest manuel par un cabinet qualifié — SecAudit ne remplace pas cet exercice.

9. Sub-Resource Integrity (SRI)

SRI est le mécanisme qui permet au navigateur de vérifier l'intégrité d'un script ou d'une feuille de styles chargée depuis un CDN tiers, via un hash cryptographique inscrit dans le HTML. L'attribut s'ajoute en quelques caractères : integrity="sha384-…" crossorigin="anonymous" sur le tag <script> ou <link>.

Sans SRI, si le CDN est compromis (cas réels : event-stream npm en 2018, polyfill.io en 2024), 100 % des visiteurs reçoivent un JavaScript attaquant — typiquement un mineur de crypto, un keylogger ou une redirection vers un paywall. L'impact est maximal et invisible côté éditeur.

SecAudit utilise cheerio pour parser le HTML servi et flaggue tous les script[src^="http"] et link[rel=stylesheet][href^="http"] sans attribut integrity. Sur 100 sites audités, 47 % chargent au moins un asset CDN sans SRI.

Fix : générer le hash via openssl dgst -sha384 -binary FILE | openssl base64 -A ou utiliser un générateur SRI gratuit en ligne (le nôtre est disponible). Côté CI, vérifier que le hash matche le hash uploadé sur le CDN (sinon le navigateur block, donc bug user-facing immédiat — c'est fail-safe par design).

10. Mixed Content

Mixed content désigne une page HTTPS qui charge au moins une ressource (script, image, iframe, fetch) en HTTP. Conséquences :

• Le navigateur bloque silencieusement le contenu actif (scripts, iframes), ce qui dégrade l'UX (widgets cassés).
• Le verrou cadenas dans la barre d'URL est soit dégradé soit absent, signal de méfiance pour l'utilisateur.
• Le SEO peut se dégrader (signal Google négatif depuis 2018).
• Sur du contenu passif (images), le contenu est servi mais interceptable en MITM, ce qui réduit la garantie de protection de la couche TLS.

SecAudit utilise cheerio pour parser le HTML et flagger tous les src="http://" et href="http://" (hors <a href>, qui sont des liens et pas des ressources chargées). Sur 100 sites HTTPS audités, 29 % avaient au moins un mixed content — typiquement un widget « Avis Vérifiés » ou un pixel Facebook posé en 2017 et jamais migré.

Fix : remplacer http:// par https:// partout, ou utiliser // (URL protocol-relative) qui hérite du protocole de la page mère.

Méthodologie SecAudit — scoring composite et fréquence

Pour qu'un audit soit actionnable, il doit produire un score unique compréhensible par un dirigeant non-technique, tout en gardant le détail accessible aux équipes techniques. Notre composite 0-100 pondère les 10 dimensions ainsi :

• TLS — 15 %
• Headers de sécurité — 15 %
• DNS — 12 %
• Fichiers exposés — 12 %
• Tech detection + CVE — 12 %
• OWASP basics — 10 %
• CORS — 8 %
• Cookies — 6 %
• Sub-Resource Integrity — 5 %
• Mixed content — 5 %

La pondération reflète le ratio impact ÷ probabilité d'exploitation. TLS et headers à 15 % chacun parce que ce sont les fondations et qu'ils touchent 100 % des visiteurs. CVE et fichiers exposés à 12 % parce que l'impact en cas de hit est maximal mais demande déjà une stack vulnérable. SRI et mixed-content à 5 % parce que l'exploitation demande une compromission préalable du CDN ou un MITM actif.

Chaque finding individuel est classé Critical / High / Medium / Low / Info selon la correspondance CVSS si applicable, ou selon une matrice interne (CSP absent = Medium, .env exposé = Critical, HSTS absent = Medium, CVE CVSS ≥ 9 = High avec confidence flag).

Fréquence d'audit recommandée :

• Mensuelle pour les sites e-commerce et SaaS actifs (déploiements fréquents = surface d'attaque changeante).
• Trimestrielle pour les sites vitrine peu modifiés.
• Post-déploiement systématique pour les sites en CI/CD continu (audit automatique sur chaque déploiement production via API SecAudit).
• Ponctuelle avant tout audit de conformité (RGPD, ISO 27001, SOC 2) — à compléter par un pentest manuel.

Le delta mensuel est l'information la plus actionnable pour le client final : « +12 points ce mois, le client a corrigé HSTS et CSP, voici les 3 priorités restantes ». Notre email récap automatique mensuel le présente sous cette forme.

Conclusion — checklist actionnable

Auditer la sécurité d'un site web en 2026 ne se résume pas à coller un lien SecurityHeaders.com. Une approche méthodique sur les 10 dimensions ci-dessus identifie 90 % des risques en moins de 30 minutes, à un coût marginal nul une fois l'outillage en place.

À faire ce mois-ci sur vos sites :

1. Lancer un scan headers + TLS gratuit sur chaque site.
2. Ajouter HSTS, CSP, X-Frame-Options, X-Content-Type-Options sur le reverse proxy.
3. Vérifier le DMARC (policy ≥ quarantine) et le SPF (terminateur -all).
4. Ajouter Secure; HttpOnly; SameSite=Lax sur tous les cookies de session.
5. Tester l'exposition de .env, /server-status, /wp-json/wp/v2/users.
6. Mettre à jour le CMS (WordPress, Drupal…) et les plugins critiques.
7. Ajouter integrity= sur tous les scripts CDN tiers.
8. Programmer un audit mensuel récurrent (manuel ou via un outil comme SecAudit).

SecAudit automatise les 10 dimensions ci-dessus et produit un rapport PDF white-label livrable à votre client. Si vous êtes agence web, freelance ou e-commerçant, le free tool /security-headers-checker est public et illimité (5/IP/24h) — testez-le sur vos sites maintenant, le résultat tombe en 8 secondes.