Liens profonds entre site et application : sécurité, confidentialité et repli

Paramètres publics, opaques et interdits

Un slug public de recette, une langue ou une source éditoriale sont des paramètres publics possibles. Un jeton opaque ne révèle aucun contenu et ne peut être interprété par le navigateur ; le serveur vérifie son audience, son expiration et son usage unique. Les données métier et identifiants sensibles restent interdits, même si le produit cible promet de les ignorer.

Une liste blanche de noms, formats et longueurs ferme le parseur. Tout paramètre inconnu est rejeté ou ignoré sans être journalisé en clair. La page canonique retire les paramètres de contexte pour éviter la duplication indexable.

Prévenir la redirection ouverte

Un paramètre return_url libre permettrait d’envoyer le visiteur vers un domaine malveillant sous couvert du site connu. Le service accepte plutôt un identifiant de destination déclaré ou un chemin relatif dans une liste blanche. L’origine, le protocole, le port et le chemin sont comparés après normalisation.

Les URL contenant identifiants intégrés, schémas non HTTP ou doubles encodages sont refusées. Une erreur renvoie vers une page locale sûre avec une explication et un bouton manuel.

Jeton opaque et consommation

Lorsqu’un parcours exige une continuité de confiance, le site backend demande un jeton au gateway privé avec une identité de service dédiée. Le navigateur ne possède ni secret HMAC ni droit d’émission. Le jeton reçu ne contient pas le payload métier ; l’application cible le consomme une seule fois et obtient seulement les champs autorisés.

Le contrôle porte sur audience, intention, expiration, révocation et usage unique. Deux consommations concurrentes ne peuvent réussir. Si le gateway n’existe pas ou si le jeton est invalide, le parcours échoue fermé et propose une action locale qui ne prétend pas vérifier ce qui ne l’est pas.

Mode autonome sans gateway

Certains parcours publics peuvent fonctionner sans jeton lorsque l’intention est entièrement publique et que l’application demande une confirmation locale. Le lien fournit par exemple un identifiant de modèle public ; l’application calcule ensuite localement à partir de ses propres données, sans import automatique depuis le site.

Ce mode doit être nommé séparément du handoff sécurisé. Il ne devient pas un raccourci pour transporter une liste ou contourner une autorisation. Le site ne reçoit aucun retour contenant des données personnelles.

Journaux, analytics et cache

Les journaux techniques conservent le chemin normalisé et un code de résultat, pas la chaîne de requête brute lorsque celle-ci peut contenir un jeton. Les mesures agrégées utilisent un nom d’événement et une catégorie de destination. Aucun paramètre de contexte n’est copié dans les propriétés analytics.

Une réponse contenant un jeton ou un état personnalisé est no-store. Les pages éditoriales et assets peuvent être mis en cache publiquement, mais le cache ne varie jamais selon un identifiant privé. Le service worker ne place pas les URLs tokenisées dans son cache hors ligne.

Repli accessible

L’ouverture automatique d’une application n’est pas fiable sur tous les navigateurs. La page explique l’action, propose un bouton explicite, puis un repli vers la PWA ou le guide. Elle n’affirme pas connaître l’état d’installation. Le focus revient sur le message de résultat et aucune boucle de redirection n’est déclenchée.

Un délai éventuel est annoncé et annulable. Le lien manuel reste utilisable au clavier. Les erreurs distinguent expiration, destination indisponible et paramètre invalide sans révéler d’information sur un compte.

Menaces et contrôles

Les risques principaux sont fuite par URL, réutilisation de jeton, confusion d’audience, redirection ouverte, élargissement de droits, journalisation et mise en cache partagée. Le contrôle n’est pas une simple signature : il combine schéma fermé, identité du service émetteur, expiration, stockage atomique, révocation et autorisation dans l’application cible.

Un lien profond ne remplace pas la session de l’application. L’application reste autorité de ses rôles et demande une confirmation lorsque l’action modifie des données.

Checklist avant publication

Vérifiez le lien exact avec des données fictives et le profil prévu, puis inspectez URL, logs et cache.

• Seuls source, langue et identifiant public nécessaires sont présents.
• Aucune donnée de foyer, séjour, santé, message ou liste n’est encodée.
• Les retours sont en liste blanche.
• Le canonical exclut les paramètres.
• Le Referer est borné lorsque nécessaire.
• Le jeton, s’il existe, expire et se consomme une fois.
• Les erreurs sont fail-closed et compréhensibles.
• Le cache partagé et le service worker excluent les réponses personnalisées.