Les requêtes HTTP contiennent des en-têtes tels que "User-Agent" ou "Content-Type". Outre les en-têtes joints par les navigateurs, les applications Android peuvent ajouter des en-têtes supplémentaires, comme Cookie ou Referrer via l'extra d'intent EXTRA_HEADERS. Pour des raisons de sécurité, Chrome filtre certains des en-têtes supplémentaires en fonction du mode et du lieu de lancement d'un intent.
Les requêtes multi-origines nécessitent une couche de sécurité supplémentaire, car le client et le serveur n'appartiennent pas à la même partie. Ce guide explique comment lancer ce type de requêtes via des onglets personnalisés Chrome, c'est-à-dire des intents lancés à partir d'applications qui ouvrent une URL dans l'onglet du navigateur. Jusqu'à Chrome 83, les développeurs pouvaient ajouter n'importe quel en-tête lors du lancement d'un onglet personnalisé. À partir de la version 83, Chrome a commencé à filtrer tous les en-têtes multi-origines approuvés, car ceux-ci présentaient un risque de sécurité. À partir de Chrome 86, il est possible de joindre des en-têtes non ajoutés à la liste d'approbation aux requêtes multi-origines, lorsque le serveur et le client sont liés à l'aide d'un digital asset link. Ce comportement est résumé dans le tableau suivant:
| Version de Chrome | En-têtes CORS autorisés |
|---|---|
| avant Chrome 83 | liste d'approbation, non répertoriée |
| De Chrome 83 à Chrome 85 | liste d'approbation |
| à partir de Chrome 86 | ajoutée à la liste d'approbation, à la liste non approuvée lors de la configuration d'un lien vers un élément numérique |
Tableau 1 : Filtrage des en-têtes CORS non approuvés
Cet article explique comment configurer une connexion validée entre le serveur et le client, et comment l'utiliser pour envoyer les en-têtes HTTP ajoutés à la liste d'approbation ainsi que les en-têtes HTTP non approuvés. Vous pouvez passer à la section Ajouter des en-têtes supplémentaires aux intents d'onglet personnalisé pour découvrir le code.
Contexte
En-têtes de demandes CORS de la liste d'approbation par rapport aux non-listes d'approbation
Le partage des ressources entre origines multiples (CORS) permet à une application Web d'une origine donnée de demander des ressources d'une origine différente. La liste des en-têtes CORS-ApprovedList est conservée dans la norme HTML. Vous trouverez des exemples d'en-têtes d'une liste d'approbation dans le tableau suivant:
| Header | Description |
|---|---|
| accepter-langue | Fait la promotion de langages naturels que le client comprend |
| langue de contenu | décrit le langage destiné au public actuel |
| type de contenu | indique le type de support de la ressource. |
Tableau 2 : Exemples d'en-têtes CORS approuvés
Les en-têtes approuvés sont considérés comme sûrs, car ils ne contiennent pas d'informations utilisateur sensibles et sont peu susceptibles d'entraîner des opérations potentiellement dangereuses sur le serveur.
Le tableau suivant présente des exemples d'en-têtes non approuvés:
| Header | Description |
|---|---|
| jeton de support | authentifie le client auprès d'un serveur |
| origin | indique l'origine de la requête. |
| biscuit | contient les cookies définis par le serveur |
Tableau 3 : Exemple d'en-têtes CORS non ajoutés à la liste d'approbation
La norme HTML empêche de joindre des en-têtes non approuvés aux requêtes CORS, car les serveurs supposent que les requêtes multi-origines ne contiennent que des en-têtes approuvés. L'envoi d'en-têtes non ajoutés à la liste d'approbation à partir de domaines multi-origines permettrait à des applications tierces malveillantes de créer des en-têtes qui utilisent de manière abusive des cookies utilisateur que Chrome (ou un autre navigateur) stocke et joint aux requêtes. Les cookies pourraient authentifier des transactions de serveur malveillantes qui, autrement, seraient impossibles.
Associer des en-têtes CORS recensés pour l'approbation des requêtes d'onglets personnalisés
Les onglets personnalisés permettent de lancer des pages Web dans un onglet personnalisé du navigateur. Les intents d'onglet personnalisé peuvent être créés à l'aide de CustomTabsIntent.Builder(). Vous pouvez également associer des en-têtes à ces intents à l'aide d'un Bundle avec l'option Browser.EXTRA_HEADERS:
CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();
Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));
Nous pouvons toujours joindre des en-têtes approuvés aux requêtes CORS dans les onglets personnalisés. Toutefois, Chrome filtre par défaut les en-têtes non ajoutés à la liste d'approbation. Bien que d'autres navigateurs puissent avoir un comportement différent, les développeurs doivent s'attendre à ce qu'ils soient bloqués de manière générale.
La méthode acceptée pour inclure des en-têtes non approuvés dans les onglets personnalisés consiste d'abord à vérifier la connexion multi-origine à l'aide d'un lien d'accès numérique. La section suivante montre comment les configurer et lancer un intent d'onglets personnalisés avec les en-têtes requis.
Ajouter des en-têtes supplémentaires aux intents de l'onglet personnalisé
Configurer Digital Asset Links
Pour autoriser la transmission via des intents d'onglet personnalisé, vous devez configurer un lien d'élément numérique entre l'application Android et l'application Web, qui vérifie que l'auteur possède les deux applications.
Suivez le guide officiel pour configurer un lien vers un contenu numérique. Pour la relation de liaison, utilisez "delegate_permission/common.use_as_origin" qui indique que les deux applications appartiennent à la même origine une fois le lien validé.
Créer un intent d'onglet personnalisé avec des en-têtes supplémentaires
Il existe plusieurs façons de créer un intent Onglets personnalisés. Vous pouvez utiliser le compilateur disponible dans AndroidX en ajoutant la bibliothèque aux dépendances de compilation:
MULTI_LINE_CODE_PLACEHOLDER_1
Créez l'intent et ajoutez des en-têtes supplémentaires:
MULTI_LINE_CODE_PLACEHOLDER_2
Connectez les onglets personnalisés pour valider le lien des éléments
Une connexion avec les onglets personnalisés permet de configurer un CustomTabsSession entre l'application et l'onglet Chrome. Nous avons besoin de la session pour vérifier que l'application et l'application Web appartiennent à la même origine.
La validation ne réussit que si les Digital Asset Links ont été configurés correctement.
Nous vous conseillons d'appeler CustomTabsClient.warmup(). Il permet à l'application de navigateur de pré-initialiser en arrière-plan et d'accélérer le processus d'ouverture de l'URL.
MULTI_LINE_CODE_PLACEHOLDER_3
Configurer un rappel qui lance l'intent après la validation
Le CustomTabsCallback a été transmis à la session. Nous avons configuré son onRelationshipValidationResult() pour lancer le CustomTabsIntent précédemment créé une fois la validation de l'origine terminée.
MULTI_LINE_CODE_PLACEHOLDER_4
Lier la connexion au service des onglets personnalisés
La liaison du service lance le service, et le onCustomTabsServiceConnected() de la connexion finira par être appelé. N'oubliez pas d'annuler la liaison du service de manière appropriée. La liaison et la dissociation sont généralement effectuées dans les méthodes du cycle de vie de l'activité onStart() et onStop().
// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
CustomTabsClient.getPackageName(MainActivity.this, null), connection);
// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);
Code de l'application de démonstration
Pour en savoir plus sur le service d'onglets personnalisés, cliquez ici. Consultez le dépôt GitHub android-browser-helper pour obtenir un exemple d'application fonctionnelle.
Résumé
Ce guide a montré comment ajouter des en-têtes arbitraires aux requêtes CORS d'onglets personnalisés. Les en-têtes ajoutés à la liste d'approbation peuvent être associés à chaque requête CORS d'onglets personnalisés. Les en-têtes non approuvés sont généralement considérés comme non sécurisés dans les requêtes CORS. Chrome les filtre par défaut. Leur association n'est autorisée que pour les clients et les serveurs de la même origine, validés par un Digital Asset Links.