> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-center-fr/email-security/link-analysis.md). # Analyse des liens Email Security inspecte les liens trouvés dans les e-mails qu’il analyse. Voici ce que nos systèmes font avec ces liens, et comment signaler un lien qui doit être laissé intact. ## Pourquoi les liens sont résolus Le phishing se trahit rarement dans le corps d’un message. L’indice se trouve dans la destination : un lien raccourci qui aboutit sur un domaine imitateur, ou une chaîne de redirections qui se termine sur un domaine enregistré il y a trois jours. Lire un lien tel qu’il est écrit ne nous apprend rien de tout cela. Il faut résoudre le lien pour voir où il mène réellement. ## Ce que fait l’analyse Pour chaque lien dans un e-mail analysé, Stoïk envoie une requête HTTP `HEAD` et suit jusqu’à cinq redirections. Un `HEAD` Cette requête demande au serveur uniquement les en-têtes de réponse. C’est la même requête que pour ouvrir la page, sans le contenu de la page. Elle est utilisée à la place d’un chargement complet de la page, car c’est le moyen le plus léger de savoir où mène un lien. À partir de là, Stoïk enregistre la fin de la chaîne de redirections, le nombre de sauts et la réputation du domaine de destination. La requête expire après deux secondes. ## Quand l’analyse va plus loin Si le domaine de destination semble suspect — c’est-à-dire s’il a une mauvaise réputation, a été enregistré récemment ou est rarement observé parmi les boîtes mail que nous protégeons — la page est ouverte dans un environnement de navigateur isolé et une capture d’écran est réalisée. Un modèle de vision juge alors s’il s’agit d’un kit de vol d’identifiants, et quelle marque il imite. Un domaine bien établi et fréquemment observé n’atteint jamais ce stade. Un lien vers un grand fournisseur est résolu, mais sa page n’est jamais chargée. Charger une page signifie que la page exécute son propre JavaScript, exactement comme dans le navigateur d’un visiteur, et une page peut émettre ses propres requêtes pendant ce temps. Ces requêtes proviennent de la page, et non des instructions que nous lui donnons. Lorsqu’une page est inaccessible à cause d’un défi anti-bot, la capture passe par un solveur qui négocie d’abord le défi. ## Ce que l’analyse ne fait jamais Stoïk n’agit pas en votre nom. Notre analyse n’appuie sur aucun bouton, ne remplit aucun formulaire et n’utilise jamais vos identifiants. Lorsqu’un lien déclencherait quelque chose du seul fait d’être demandé, il n’est pas demandé du tout : voir [Liens totalement ignorés](#links-that-are-skipped-entirely). ### Exception : plateformes de partage de fichiers Les attaquants font transiter une part croissante de leurs campagnes de phishing par des services légitimes de partage de fichiers. Un document partagé depuis une plateforme connue emprunte la réputation de cette plateforme et franchit la plupart des filtres, tandis que le piège se trouve à l’intérieur du fichier partagé. Évaluer cet e-mail signifie lire ce qui a réellement été partagé. Ces plateformes ne remettent pas un document partagé à un simple chargement de page. Y accéder signifie effectuer la requête que la plateforme définit pour lui : une requête vers sa propre API, ou l’étape d’authentification anonyme qu’exécute un lien de partage en utilisant la clé déjà contenue dans le lien. Stoïk ne le fait que sur les plateformes qu’il prend explicitement en charge, et uniquement avec ce que le lien contient déjà. ## Liens totalement ignorés Certains liens modifient quelque chose dès qu’ils sont sollicités, même par un `HEAD`. Un lien de signature électronique peut marquer un document comme consulté ou consommer un jeton à usage unique. Un lien de digest de quarantaine peut libérer un e-mail bloqué. Un lien de désabonnement en un clic retire le destinataire d’une liste de diffusion, et un lien d’invitation de calendrier peut enregistrer une réponse RSVP. La norme HTTP est explicite à ce sujet. La section 9.2.1 de la RFC 9110 définit `GET` et `HEAD` comme des méthodes sûres : un client qui en envoie une ne demande ni n’attend de changement d’état sur le serveur. La même section ajoute que lorsqu’un paramètre dans l’URL sélectionne une action, le propriétaire de cette ressource doit désactiver l’action lorsqu’elle est atteinte avec une méthode sûre. La règle existe pour que la récupération automatisée puisse fonctionner sans causer de dommages. Tous les services ne la respectent pas. {% hint style="info" %} Stoïk conserve une liste d’autorisation de destinations qui sont complètement ignorées, sans qu’aucune requête ne soit envoyée. Elle couvre les plateformes de signature électronique, les portails de quarantaine d’e-mails, les points de terminaison de désabonnement aux newsletters et les réponses aux invitations de calendrier. {% endhint %} ## Signaler un lien Si vous voyez une action sur l’un de vos services que vous pensez provenir de notre analyse, signalez-la à Stoïk via votre canal d’assistance habituel. Détails utiles : * Le service concerné * L’adresse de la boîte mail concernée * À peu près quand cela s’est produit * Le lien lui-même, si vous l’avez encore La destination est ajoutée à la liste d’autorisation, et vous êtes informé une fois le changement effectif. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-center-fr/email-security/link-analysis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.