Exemple de Rapport — Website Security Deep Review (499 €)

Voici à quoi ressemble une vraie évaluation de sécurité.

Le rapport est rédigé pour les dirigeants, propriétaires et décideurs — pas seulement pour les équipes techniques. Compréhensible, honnête, avec des risques réalistes et des mesures pratiques. Pas de vente par la peur. Voici un extrait d'un rapport réel.

1. Résumé pour la Direction

Entreprise Exemple SARL — entreprise-exemple.fr

Examiné le 14 mai 2026 · Autorisé par écrit · Analyse externe passive · Auditeur : SAB Security, Karlsruhe

domaines examinés

actions requises (Moyen)

recommandations (Faible)

confirmé sécurisé

Impression générale : Le site web est fondamentalement bien configuré. HTTPS, HSTS et les en-têtes de sécurité les plus importants sont correctement paramétrés. Aucun panneau d'administration ouvert, aucune sauvegarde de base de données et aucun fichier de configuration sensible n'ont été trouvés. Le besoin d'action le plus important se situe dans le domaine des e-mails : DKIM est absent et DMARC est réglé sur surveillance uniquement. Sans DKIM, des e-mails falsifiés peuvent être envoyés au nom du domaine — un risque pertinent pour la confiance des clients et les fausses factures.

Conclusion : Aucune faille de sécurité critique. Deux problèmes de sévérité moyenne avec un risque commercial réel (DKIM absent, lacune de processus RGPD dans le formulaire de contact). Toutes les recommandations techniques peuvent être mises en œuvre avec un effort minimal. Un court nouveau test après correction est inclus dans le forfait Deep Review.

2. Périmètre & Autorisation

Ce qui a été examiné

DNS : A, AAAA, MX, TXT, SPF, DKIM, DMARC
Redirection HTTP→HTTPS et comportement www/non-www
Certificat TLS et chiffrement
En-têtes de sécurité (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
Fichiers accessibles publiquement (.env, .git, sauvegardes, robots.txt, sitemap.xml, security.txt)
Détection de CMS / panneau d'administration
Formulaire de contact : validation, consentement, honeypot, XSS basique, limitation de débit

Ce qui n'a délibérément pas été examiné

Aucune attaque par force brute
Aucun test de déni de service
Aucune ingénierie sociale
Aucun test destructif
Aucun accès aux systèmes ou données protégés
Aucun partage d'identifiants

Cet examen a été réalisé avec l'autorisation écrite du client. Tous les tests étaient passifs, non destructifs et limités aux informations publiquement disponibles.

3. Méthodologie

L'examen suit un processus standardisé et reproductible — comparable au premier regard d'un attaquant sur le site web public, mais contrôlé, documenté et sans actions nuisibles.

Tous les tests sont effectués depuis Karlsruhe, Allemagne. Chaque étape de contrôle est consignée avec la date, l'heure et le résultat. Outils utilisés : requêtes DNS (dig), analyse des en-têtes HTTP (curl), vérification TLS (openssl), et examen manuel des entrées identifiées.

Le rapport utilise une évaluation réaliste et orientée métier :

Moyen — Risque commercial réel (abus, conformité, confiance client)
Faible — Durcissement, sécurisation supplémentaire, petites améliorations
Info — Observation, aucune mesure immédiate nécessaire

Les constatations uniquement théoriques ou sans impact commercial démontrable ne sont pas incluses. Pas de « critique » sans chemin d'exploitation prouvé.

4. Constatations Détaillées

DKIM absent — usurpation d'e-mail possible

Moyen

Résultat : Aucun enregistrement DKIM trouvé pour le domaine. Sélecteurs vérifiés : default, google, selector1, selector2, mail, k1, cloudflare, cf.

selector1._domainkey.entreprise-exemple.fr TXT :
Aucun enregistrement trouvé.

Impact Commercial

Sans DKIM, il n'y a aucune preuve cryptographique que les e-mails de @entreprise-exemple.fr proviennent réellement de vous. Un attaquant peut falsifier des e-mails avec votre adresse d'expéditeur — par exemple, une fausse facture à vos clients ou une demande de paiement manipulée. DKIM est le troisième pilier de l'authentification des e-mails avec SPF et DMARC. Cette lacune est particulièrement pertinente pour une entreprise qui envoie des factures ou des informations confidentielles par e-mail.

Recommandation : Configurez la signature DKIM chez votre fournisseur de messagerie (Google Workspace, Microsoft 365, Cloudflare Email Routing, etc.). Le fournisseur fournit la clé publique à publier comme enregistrement DNS TXT. Effort : environ 15 minutes. Ensuite, passez SPF à -all et DMARC à p=quarantine.

DMARC sur p=none — aucune application

Faible

Résultat : DMARC est présent mais réglé sur p=none (surveillance uniquement).

_dmarc.entreprise-exemple.fr TXT :
"v=DMARC1; p=none; rua=mailto:[email protected]"

Impact Commercial

p=none signifie que les e-mails non authentifiés sont signalés mais ni rejetés ni envoyés en spam. Les e-mails falsifiés atteignent toujours les destinataires. La surveillance est une bonne première étape, mais devrait être renforcée à p=quarantine après évaluation des rapports.

Recommandation : Après la configuration de DKIM, évaluez les rapports DMARC pendant 2 à 4 semaines. Si aucun e-mail légitime n'échoue, passez à p=quarantine (pct=25 pendant 2 semaines, puis pct=100).

Consentement RGPD dans le formulaire de contact non vérifié côté serveur

Moyen

Résultat : Le formulaire de contact vérifie la case de consentement à la protection des données uniquement dans le navigateur (côté client). Un appel POST direct sans privacy_consent est accepté par le serveur.

POST /scan/contact avec privacy_consent:false →
{"ok":true} — la demande a été enregistrée sans consentement.

Impact Commercial

Selon le RGPD, le traitement des données personnelles doit reposer sur un consentement documenté. Si le consentement n'est vérifié que côté client, des données peuvent être stockées sans autorisation — une lacune de processus avec des risques potentiels de conformité. Risque pratique : faible (uniquement des demandes de contact). Risque juridique : présent.

Recommandation : Ajoutez une vérification côté serveur : refusez les demandes avec privacy_consent !== true par HTTP 400. Effort : environ 5 minutes.

La CSP autorise 'unsafe-inline' et 'unsafe-eval'

Faible

Résultat : La Content Security Policy inclut 'unsafe-inline' et 'unsafe-eval' dans script-src.

Impact Commercial

Ces entrées affaiblissent la protection XSS de la CSP. Cependant, dans la configuration actuelle, elles sont nécessaires car le site utilise des scripts inline légitimes. Le risque est faible car le site est statique et n'affiche pas dynamiquement de contenu utilisateur.

Recommandation : À moyen terme : migrer les scripts inline vers des fichiers .js externes (avec nonce ou hash). Tant que le site n'affiche pas de contenu utilisateur dynamique, la configuration actuelle est acceptable.

Clé PGP référencée dans security.txt inaccessible

Faible

Résultat : Le fichier security.txt référence une clé PGP sous /.well-known/pgp-key.txt, qui retourne HTTP 403 (Forbidden).

Impact Commercial

Les chercheurs en sécurité qui souhaitent signaler une vulnérabilité de manière confidentielle ne peuvent pas chiffrer leur message. Risque pratique faible, mais une occasion manquée de communication de confiance.

Recommandation : Soit publier la clé PGP (ajuster la règle nginx), soit supprimer la référence du security.txt. Effort : 2 minutes.

5. Mesures de Sécurité Confirmées

Domaine de Contrôle	Résultat
HTTPS & TLS	TLS 1.3, certificat Let's Encrypt valide	Sécurisé
Redirection HTTP→HTTPS	Redirection 301 fonctionne correctement	Sécurisé
HSTS (HTTP Strict Transport Security)	max-age=31536000; includeSubDomains; preload	Sécurisé
X-Frame-Options / X-Content-Type-Options	SAMEORIGIN / nosniff — correctement définis	Sécurisé
Referrer-Policy / Permissions-Policy	Restrictif et configuré de manière sensée	Sécurisé
Fichiers sensibles	.env, .git/* bloqués avec 403	Sécurisé
Aucun panneau d'administration	Pas de /wp-admin, /admin, backend CMS exposé	Sécurisé
robots.txt / sitemap.xml / security.txt	Tous les trois présents et corrects	Présent

6. Nouveau Test (inclus dans le forfait Deep Review)

Le Website Security Deep Review (499 €) comprend exactement un court nouveau test après que vous ayez mis en œuvre les mesures recommandées.

Constatation	Statut
DKIM absent	Ouvert
DMARC p=none	Ouvert
Consentement RGPD côté serveur	Ouvert
CSP unsafe-inline	Risque Accepté
Clé PGP inaccessible	Ouvert

Corrigé — passé à ce statut après un nouveau test réussi.
Risque Accepté — délibérément non corrigé, documenté.
Ouvert — pas encore traité.

7. Prochaines Étapes Recommandées

Priorité	Action	Effort
1	Configurer DKIM chez votre fournisseur de messagerie	~15 min.
2	Ajouter la vérification du consentement RGPD côté serveur	~5 min.
3	Passer DMARC à p=quarantine après DKIM	~5 min.
4	Publier la clé PGP ou supprimer la référence	~2 min.
5	Migrer les scripts inline vers des fichiers externes (long terme)	~1 h

Ceci est un extrait d'un véritable rapport Deep Review. Chaque rapport est adapté individuellement à votre domaine et à votre situation — avec des recommandations concrètes et actionnables. Pas de sortie de scanner générique.

Demander un Website Security Deep Review — 499 € → Voir les tarifs