flawopen.com/Sécurité d’Android WebView/addJavascriptInterface

Android addJavascriptInterface : risques et usage sûr

Page de référence

Réponse courte

Considérez une WebView avec addJavascriptInterface comme une frontière privilégiée. Android injecte l’objet dans chaque frame et l’application ne peut pas savoir quelle frame l’a appelé. Si du JavaScript contrôlé par un attaquant atteint une frame, il peut appeler les méthodes exposées avec les permissions de l’application. Réservez les WebView avec pont au contenu contrôlé par l’application et chargez les pages non fiables dans une autre WebView sans ce pont.

Pourquoi le pont change l’impact d’une XSS

Un pont fournit au JavaScript des points d’entrée appelables dans l’application hôte. Android expose l’objet à toutes les frames, y compris les iframes, et addJavascriptInterface ne vérifie pas l’origine de la frame appelante. Un script injecté peut donc atteindre les méthodes annotées ; ses capacités dépendent de ces méthodes et des contrôles d’autorisation de l’application. Pour les applications ciblant l’API 16 ou antérieure, Android documente un comportement historique plus grave : toutes les méthodes publiques peuvent être exposées. À partir de l’API 17, @JavascriptInterface est requis, mais cette annotation ne rend pas le contenu non fiable sûr.

Éloignez le pont des pages non fiables

RISQUÉ — pont et navigation non fiable dans la même WebView

webView.addJavascriptInterface(
  NativeBridge(), "Android"
)
webView.loadUrl(untrustedUrl)

PLUS SÛR — séparer les contenus fiables et non fiables

// Cette WebView est réservée à l’interface intégrée contrôlée par l’application.
trustedWebView.settings.javaScriptEnabled = true
trustedWebView.addJavascriptInterface(
  NativeBridge(), "Android"
)
trustedWebView.loadUrl("file:///android_asset/index.html")

// Une autre WebView gère les pages distantes ou contrôlées par des utilisateurs.
untrustedWebView.removeJavascriptInterface("Android")
untrustedWebView.settings.javaScriptEnabled = false
// Vérifiez HTTPS et une liste d’autorisation explicite des hôtes.
untrustedWebView.loadUrl(validatedHttpsUrl)

La frontière la plus solide est architecturale : ne naviguez jamais depuis une WebView avec pont vers une page distante, créée par un utilisateur ou influencée par un attaquant. Si le chargement d’un contenu non fiable est inévitable, supprimez l’interface avant le chargement et utilisez une WebView séparée avec JavaScript désactivé sauf nécessité. Android précise que l’objet injecté est disponible dans toutes les frames et que la suppression ne prend effet qu’après le prochain chargement de page. HTTPS protège le transport ; il ne rend fiables ni un hôte ni son contenu. Vérifiez le schéma et l’hôte de l’URL, puis ouvrez les liens hors liste dans le navigateur système. Limitez les méthodes du pont, validez chaque argument et appliquez l’autorisation en code natif sans faire confiance à la page appelante.

FAQ sur la sécurité des ponts WebView

L’API 17 ou ultérieure rend-elle addJavascriptInterface sûr ?

Non. L’API 17+ limite l’exposition aux méthodes publiques annotées avec @JavascriptInterface ; elle ne vérifie pas l’origine de la frame et ne rend pas fiable un contenu contrôlé par un attaquant. Réservez le pont à une WebView qui ne charge que du contenu contrôlé par l’application.

Références

À voir aussi Cross-Site Scripting (XSS, CWE-79) : fonctionnement et prévention dans chaque langage — flawopen.com Angular : XSS, valeurs sûres et API de bypass XSS par MIME sniffing : Content-Type et nosniff CSP et échappement de sortie : faut-il les deux ? dangerouslySetInnerHTML est-il sûr dans React ? DOMPurify suffit-il pour sécuriser innerHTML ? Markdown protège-t-il contre les XSS ?