Mobile Network Security

Cleartext Traffic, ATS und Network Security

Globale HTTP-Ausnahmen lösen oft nur ein Entwicklungsproblem und hinterlassen ein Sicherheitsrisiko. Der Produktionsbuild braucht enge, nachvollziehbare Regeln.

LaunchLint Academy

17 Minuten LesezeitRedaktion und Quellenprüfung: Rene DresselRedaktionelle Richtlinie
Sichere HTTPS-Verbindung passiert ATS und Android Network Security Configuration
HTTP-Ausnahmen lösen kurzfristig Entwicklungsprobleme, können aber Daten offenlegen und eine zu breite Produktionskonfiguration hinterlassen. Bevorzuge HTTPS und begrenze unvermeidbare Ausnahmen auf exakt bekannte Ziele.
TL;DR

Die kurze Antwort

HTTP-Ausnahmen lösen kurzfristig Entwicklungsprobleme, können aber Daten offenlegen und eine zu breite Produktionskonfiguration hinterlassen. Bevorzuge HTTPS und begrenze unvermeidbare Ausnahmen auf exakt bekannte Ziele.

  • Prüfe iOS ATS, Android Network Security Config, WebViews, Debug-Zertifikate und tatsächlich verwendete Endpunkte gemeinsam. Eine globale Freigabe ist selten die richtige Lösung.

Nachweise für die Release-Freigabe

Prüfe ats, cleartext traffic und netzwerk-sicherheitskonfiguration nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Trenne bei ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration drei Nachweise: statisch erkennbare Projektkonfiguration, Verhalten auf einem sauberen Gerät und externe Einstellungen in Apple Developer, App Store Connect oder Play Console. Erst wenn diese Ebenen denselben Release-Kandidaten beschreiben, ist die Prüfung belastbar. Dokumentiere Abweichungen mit Owner und Stop-Kriterium, statt sie als vermeintlichen Standardwert zu akzeptieren.

Nachweise für die Release-Freigabe

  • Produktionswert für alle endpunkte inventarisieren eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

1. Alle Endpunkte inventarisieren

Erfasse APIs, Auth, Medien, WebViews, Analytics, Update- und Supportdienste einschließlich Redirects und Subdomains.

Prüfe alle endpunkte inventarisieren nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für alle endpunkte inventarisieren eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

2. ATS-Standard verstehen

Apple schützt Verbindungen über das URL Loading System. Prüfe NSAppTransportSecurity und vermeide globale Freigaben.

Prüfe ats-standard verstehen nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für ats-standard verstehen eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

3. Android Cleartext kontrollieren

Prüfe usesCleartextTraffic und eine vorhandene Network Security Config. Ziel-API und Bibliothek beeinflussen die tatsächliche Durchsetzung.

Prüfe android cleartext kontrollieren nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für android cleartext kontrollieren eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

4. Ausnahmen eng begrenzen

Erlaube HTTP oder eigene Vertrauensanker nur für konkrete Domains und dokumentierten Zweck. Vermeide pauschale Base-Configs.

Prüfe ausnahmen eng begrenzen nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für ausnahmen eng begrenzen eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

5. Debug und Produktion trennen

Lokale CAs, Proxies und Entwicklungsserver gehören in Debug Overrides oder getrennte Builds, nicht in den Store-Kandidaten.

Prüfe debug und produktion trennen nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für debug und produktion trennen eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

6. WebViews gesondert prüfen

WebViews können eigene Navigation, Datei-URLs und fremde Inhalte laden. Sichere Transportregeln ersetzen keine URL-Allowlist.

Prüfe webviews gesondert prüfen nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für webviews gesondert prüfen eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

7. Zertifikate und Redirects testen

Prüfe abgelaufene Zertifikate, Hostnamen, Zwischenzertifikate und Weiterleitungen auf HTTP mit dem finalen Build.

Prüfe zertifikate und redirects testen nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für zertifikate und redirects testen eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

8. Risiko und Ausnahme dokumentieren

Jede Ausnahme braucht Owner, Ablaufdatum, betroffene Daten, Alternative und einen Test, der ihre spätere Entfernung bestätigt.

Prüfe risiko und ausnahme dokumentieren nicht als isolierten Schalter, sondern im Zusammenhang mit ATS, Cleartext Traffic und Netzwerk-Sicherheitskonfiguration, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.

Nachweise für die Release-Freigabe

  • Produktionswert für risiko und ausnahme dokumentieren eindeutig benannt
  • Verantwortliche Projektdatei oder Store-Einstellung verlinkt
  • Aufgelöste native Konfiguration kontrolliert
  • Signiertes Artefakt auf sauberem Gerät geprüft
  • iOS- und Android-Unterschiede dokumentiert
  • Offene Abweichung mit Owner und Stop-Kriterium versehen

Häufige Fragen

Warum funktioniert localhost, aber Produktion nicht?

Debug-Konfiguration, Zertifikate und Plattformregeln unterscheiden sich. Teste den echten Produktionshost im signierten Build.

Soll ich ATS komplett deaktivieren?

In der Regel nein. Behebe den Server oder nutze eine eng begrenzte, begründete Ausnahme.

Reicht usesCleartextTraffic=false?

Nicht allein. Network Security Config, WebViews und verwendete Netzwerkbibliotheken müssen ebenfalls betrachtet werden.

Kann LaunchLint Netzwerkverkehr sehen?

Nein. Es erkennt statische Konfigurationen und riskante Ausnahmen, führt die App aber nicht aus und beobachtet keinen Laufzeitverkehr.

Offizielle Primärquellen

Dieser Beitrag stützt sich auf die folgenden offiziellen Primärquellen. Store-Regeln können sich ändern; prüfe vor einer Einreichung immer die aktuelle Fassung.