Sécurité réseau mobile

Trafic HTTP, ATS et sécurité réseau

Une exception globale résout souvent le développement tout en exposant la production.

LaunchLint Academy

17 min de lectureÉdition et vérification des sources : Rene DresselPolitique éditoriale
Connexion HTTPS sécurisée traversant ATS et Network Security Configuration
Les exceptions HTTP peuvent aider au développement mais exposer des données et laisser une configuration trop large. Préférez HTTPS et limitez les exceptions.
TL;DR

La réponse courte

Les exceptions HTTP peuvent aider au développement mais exposer des données et laisser une configuration trop large. Préférez HTTPS et limitez les exceptions.

  • Contrôlez ensemble ATS, Network Security Config, WebViews, certificats de debug et points d’accès réels.

Preuves nécessaires avant publication

Ne contrôlez pas ats, trafic http et sécurité réseau comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Séparez trois niveaux de preuve pour ATS, trafic HTTP et sécurité réseau : configuration visible dans les fichiers, comportement sur un appareil propre et réglages externes dans Apple Developer, App Store Connect ou Play Console. Le contrôle n’est fiable que si ces niveaux décrivent le même candidat. Attribuez chaque écart à un responsable avec un critère d’arrêt.

Preuves nécessaires avant publication

  • Valeur de production pour inventorier les points d’accès identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

1. Inventorier les points d’accès

Incluez API, auth, médias, WebViews, analytics et redirections.

Ne contrôlez pas inventorier les points d’accès comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour inventorier les points d’accès identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

2. Comprendre ATS

Inspectez NSAppTransportSecurity et évitez les exceptions globales.

Ne contrôlez pas comprendre ats comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour comprendre ats identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

3. Contrôler HTTP Android

Vérifiez usesCleartextTraffic et Network Security Config.

Ne contrôlez pas contrôler http android comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour contrôler http android identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

4. Limiter les exceptions

Autorisez seulement domaines et buts documentés.

Ne contrôlez pas limiter les exceptions comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour limiter les exceptions identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

5. Séparer le debug

CA locales et proxies ne doivent pas rester dans le candidat.

Ne contrôlez pas séparer le debug comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour séparer le debug identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

6. Examiner les WebViews

La sécurité du transport ne remplace pas une liste d’URL.

Ne contrôlez pas examiner les webviews comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour examiner les webviews identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

7. Tester les certificats

Contrôlez expiration, hôtes, chaîne et redirections.

Ne contrôlez pas tester les certificats comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour tester les certificats identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

8. Documenter le risque

Chaque exception exige responsable, date et plan de retrait.

Ne contrôlez pas documenter le risque comme un réglage isolé. Reliez-le à ATS, trafic HTTP et sécurité réseau, à l’artefact de production signé et aux valeurs de la console. Notez quel fichier produit le réglage, si un framework ou un plugin peut le modifier pendant la construction et comment la valeur résolue a été vérifiée. Une valeur plausible dans le projet ne prouve pas que le binaire envoyé contient la même configuration.

Preuves nécessaires avant publication

  • Valeur de production pour documenter le risque identifiée
  • Fichier ou réglage responsable relié
  • Configuration native résolue contrôlée
  • Artefact signé testé sur un appareil propre
  • Écarts iOS et Android documentés
  • Chaque écart possède responsable et critère d’arrêt

Questions fréquentes

Pourquoi localhost fonctionne-t-il ?

Debug et production utilisent des règles différentes.

Faut-il désactiver ATS ?

En général non ; corrigez le serveur ou limitez l’exception.

usesCleartextTraffic=false suffit-il ?

Non. Contrôlez configuration, WebViews et bibliothèques.

LaunchLint voit-il le trafic ?

Non. Il analyse uniquement la configuration statique.

Sources primaires officielles

Cet article s’appuie sur les sources officielles ci-dessous. Les règles peuvent évoluer : vérifiez leur version actuelle avant chaque soumission.