Ressources · 116
postMessage : vérifier origine, fenêtre et commande reçue
Définir un contrat pour les échanges avec une iframe ou une fenêtre afin de refuser les messages inattendus.
· 2 min
Ce que ce guide permet
- Définir les interlocuteurs et le contrat
- Valider avant tout effet
- Tester navigation et messages hors contrat
Contrôle express
- Contrat origine, fenêtre, type et données minimales.
- Chaîne de validation et refus sans effet métier.
- Matrice de refus et nettoyage des écouteurs.
Méthode pas à pas
- 01
Définir les interlocuteurs et le contrat
Listez les origines exactes attendues, la référence de fenêtre et les types de messages utiles. Pour les échanges contenant des données sensibles, utilisez un targetOrigin précis. Une origine inclut protocole, hôte et port ; une recherche de sous-chaîne dans un nom de domaine ne valide pas cet interlocuteur.
Contrat origine, fenêtre, type et données minimales.
- 02
Valider avant tout effet
À la réception, comparez event.origin et, pour cette intégration de fenêtres, event.source à la référence attendue. Validez ensuite le schéma, les valeurs autorisées et l’état de l’opération. Traitez le contenu comme des données, sans eval ni injection HTML. Une origine admise ne remplace pas l’autorisation côté serveur d’une action sensible.
Chaîne de validation et refus sans effet métier.
- 03
Tester navigation et messages hors contrat
Testez un domaine ressemblant, un port différent, une autre fenêtre de même origine, des champs invalides et un message arrivé après fermeture. Supprimez les écouteurs inutiles et invalidez les échanges terminés. Vérifiez qu’une réponse utilise une origine déjà approuvée, même si la fenêtre a navigué.
Matrice de refus et nettoyage des écouteurs.
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}Décision attendue
Exemple fictif : le message vient de https://widget.example, une origine approuvée, mais event.source est une autre fenêtre. Le contrat impose la fenêtre de l’iframe active : le message est rejeté sans lancer de commande.
Votre carnet de recette
Consignez vos observations pour les critères de ce guide. Un relevé ne constitue pas une certification.
Le carnet ne sauvegarde pas automatiquement. Exportez avant de quitter.
Les filtres ne limitent pas les exports. La liste d’actions retient les blocages et critères non examinés.
L’import remplace les observations courantes après votre confirmation.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Cas inattendus rejetés | Cas négatifs rejetés sans effet / cas négatifs exécutés | Décrire chaque origine, fenêtre et état |
| Échanges autorisés réussis | Scénarios prévus terminés / scénarios prévus testés | Ne pas confondre réception et effet confirmé |
Erreurs fréquentes
Questions fréquentes
Vérifier event.origin suffit-il pour accepter une commande ?
Non. Vérifiez aussi la fenêtre attendue, la structure et l’état du message. Le serveur doit toujours contrôler les droits nécessaires à l’action demandée.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
