L’essentiel à retenir
Lire le schéma, le domaine réel, les sous-domaines, encodages et paramètres sans ouvrir le lien ni conclure sur un seul signal.
Vingt outils locaux pour secrets aléatoires, empreintes, emails, liens, CSP, DMARC et en-têtes. Ils aident au diagnostic sans scanner de serveur ni garantir une sécurité complète.
Les points qui changent réellement la décision
1. La partie décisive d’une URL est l’hôte situé après le schéma et avant le premier slash.
Action : Ne pas cliquer.
Preuve à conserver : Noter l'hypothèse et la donnée qui permet de la contrôler.
2. Un nom de marque placé dans le chemin ou un sous-domaine ne prouve pas l’identité du domaine enregistré.
Action : Copier seulement le lien.
Preuve à conserver : Tester un cas normal puis un contre-exemple volontaire.
3. Les identifiants avant @ et le punycode peuvent faciliter une confusion visuelle.
Action : Identifier l’hôte réel.
Preuve à conserver : Faire relire le point par la personne concernée par la décision.
4. En cas de doute, il vaut mieux rejoindre le service par un favori ou une saisie manuelle.
Action : Contacter l’organisation par un canal connu.
Preuve à conserver : Conserver la date, la source et la version finalement retenue.
Appliquer la méthode sans automatiser la décision
Pour appliquer « Examiner un lien suspect sans l’ouvrir » à une situation réelle : Avant toute action, l'élément d'origine est conservé et l'analyse locale est complétée par les journaux, le DNS ou l'équipe compétente. Le premier point à éprouver est : La partie décisive d’une URL est l’hôte situé après le schéma et avant le premier slash.
| Point à examiner | Action concrète | Trace utile |
|---|---|---|
| La partie décisive d’une URL est l’hôte situé après le schéma et avant le premier slash. | Ne pas cliquer | Noter l'hypothèse et la donnée qui permet de la contrôler. |
| Un nom de marque placé dans le chemin ou un sous-domaine ne prouve pas l’identité du domaine enregistré. | Copier seulement le lien | Tester un cas normal puis un contre-exemple volontaire. |
| Les identifiants avant @ et le punycode peuvent faciliter une confusion visuelle. | Identifier l’hôte réel | Faire relire le point par la personne concernée par la décision. |
| En cas de doute, il vaut mieux rejoindre le service par un favori ou une saisie manuelle. | Contacter l’organisation par un canal connu | Conserver la date, la source et la version finalement retenue. |
Passer du besoin au bon contrôle
Les secrets utilisent Crypto.getRandomValues lorsque le navigateur le permet. Les analyseurs appliquent des règles transparentes à la valeur collée et n’effectuent aucune requête distante cachée.
- 1
Ne pas cliquer avant d’ouvrir l’outil.
- 2
Copier seulement le lien sur un exemple court et vérifiable.
- 3
Identifier l’hôte réel puis valider sur le support destinataire.
Checklist pratique
- Ne pas cliquer
- Copier seulement le lien
- Identifier l’hôte réel
- Contacter l’organisation par un canal connu
Références utilisées
- Dix règles d’or en matière de sécurité numérique — ANSSI
- Uniform Resource Identifier — syntaxe générique — RFC Editor
Consultez aussi les références de la rubrique et les tests des outils associés.
Ce que ce dossier ne remplace pas
Un score de mot de passe, une syntaxe SPF ou un en-tête présent ne suffisent jamais à prouver la sécurité d’un système. Les contrôles doivent être intégrés à une analyse de risque, des tests autorisés et une configuration serveur réelle.
Une règle contractuelle, une documentation officielle plus récente, un paramétrage de production ou un professionnel compétent prévaut toujours sur un exemple général.