WebView : le cheval de Troie des applications mobiles

Imaginez un outil transformant votre application mobile en un navigateur miniature : c'est le rôle de WebView. Ce composant essentiel permet d'afficher des contenus web directement dans les applications mobiles. Ce composant est très pratique et très utilisé, car il permet d’intégrer facilement et économiquement des fonctionnalités dans les applications mobiles. Il est toutefois crucial de ne pas sous-estimer les risques de sécurité qu'il implique.
Dans cet article, nous explorerons la nature de WebView, les dangers potentiels qu'il présente, et des stratégies clés pour sécuriser vos applications mobiles.

Des qestions sur les webviews ? Contactez-nous !

Qu'est-ce qu’une WebView?

La WebView est un élément intégré par les plateformes mobiles pour visualiser le contenu web au sein d'une application mobile. Comparable à un navigateur intégré, elle offre aux développeurs la possibilité d'insérer directement du contenu web dans leurs applications. Cette flexibilité dans la conception de l'interface utilisateur est puissante, mais elle nécessite une vigilance accrue en matière de sécurité. Cela permet également de limiter le contenu embarqué, et donc de faire perdre du poids à son application mobile. Cependant, avec ce grand pouvoir vient la grande responsabilité de la sécurité.

Les failles de sécurité “offertes” par les WebView

Le principal danger réside dans la possibilité de créer un lien entre le JavaScript et le code natif de l'application. Ce "pont" peut être exploité pour accéder à des fonctionnalités sensibles et mettre les utilisateurs en danger.
Un autre risque est l'utilisation imprudente de WebView pouvant entraîner des vulnérabilités XSS (Cross-Site Scripting).
Des scripts malveillants sont alors injectés dans les pages web de l'application.
Cela ouvre la porte aux attaques, compromettant la sécurité des données des utilisateurs.

Préconisations pour Sécuriser votre WebView

Pour atténuer ces risques et garantir la sécurité de vos applications, voici quelques recommandations essentielles :

• Privilégiez les connexions sécurisées. Utilisez exclusivement HTTPS pour vos communications.
• Activez JavaScript uniquement sur des pages dont vous maîtrisez entièrement le contenu et désactivez-le pour les autres.
• Restreignez strictement l'accès aux seuls domaines de confiance.
• Limitez les interactions JavaScript entre l'application et le contenu web. L'application doit toujours garder le contrôle sur le contenu.
• Bloquez l'accès aux fichiers locaux via WebView. Les URL "file://" peuvent constituer un risque de sécurité majeur.

Il est vital de mettre en œuvre ces mesures pour protéger efficacement vos utilisateurs. La sécurité doit toujours être votre préoccupation première.
Pour plus d'informations sur la sécurisation de WebView dans vos applications mobiles, n'hésitez pas à nous contacter ou à découvrir nos services d'audit.

Les pièges à éviter avec les webviews : retours d’expérience

Comme indiqué en début d'article, les webviews restent des composants qui sont très souvent utilisés dans les applications mobiles et qui peuvent avoir une valeur ajoutée.
Cependant, il y a un certains nombres de pièges qu'il faut savoir éviter lorsqu'on intègre des webviews dans on app, notamment le risque de dégrader l'expérience utilisateur de son application.

Voici quelques exemples courants de dégradation de l'UX d'une app par les webviews :

• Créer une nouvelle navigation au sein de la webview
• Rompre l'identité visuel de l'application mobile en affichant une page dont l'UI est différente au sein de la webview
• Diminuer le taux de rétention utilisateur en éloignant le client de sa marque : c'est le cas lorsqu'on affiche un lien externe à son domaine dans la webview
• Dégrader l'accessibilité de son aoplication mobile : l'utilisation d'une webview ne doit pas impacter l'UI du produit et toutes les guidelines qui pourraient être suivies en termes d'accessibilité

Comment bien implémenter techniquement une webview ?

Pour bien développer une webview, il est préconisé d'utiliser un des deux composants suivants : SFSafariViewController ou WKWebView.
Le choix entre SFSafariViewController, WKWebView, et d'autres options dépend des besoins spécifiques de l'application en termes d'interaction utilisateur, de personnalisation, et de sécurité. SFSafariViewController est idéal pour les cas d'utilisation où une expérience de navigation complète est nécessaire sans besoin de personnalisation poussée ou d'intégration profonde avec l'application, c'est le composant directement préconisé par Apple pour iOS.

SFSafariViewController

L'utilisation de SFSafariViewController dans les applications iOS pour afficher une webview présente plusieurs avantages et inconvénients.

Intégration du navigateur Safari

SFSafariViewController utilise le moteur de rendu de Safari, ce qui signifie que les pages se chargent de la même manière que dans le navigateur Safari. Cela inclut l'accès à des fonctionnalités avancées telles que l'AutoFill, la prévention du suivi, et les cookies partagés avec Safari. Le développeur bénéficie automatiquement des mises à jour de Safari.

Expérience utilisateur familière

Les utilisateurs reconnaissent l'interface utilisateur et les interactions du navigateur Safari, ce qui peut améliorer l'expérience utilisateur et la confiance dans l'application.

Moins de développement

SFSafariViewController est facile à implémenter et ne nécessite pas de gestion détaillée du rendu web ou des interactions utilisateur, contrairement à WKWebView.

Sécurité :

Comme SFSafariViewController est isolé de l'application hôte, les données sensibles de l'utilisateur sont mieux protégées. L'application n'a pas accès aux données de l'utilisateur telles que les cookies ou les informations de session.

Contrôle limité :

Avec SFSafariViewController, les développeurs ont un contrôle limité sur le navigateur. Par exemple, il n'est pas possible de personnaliser entièrement l'interface utilisateur ou de gérer finement les cookies et le cache.

Interaction avec l'application :

SFSafariViewController fonctionne de manière indépendante de l'application qui l'appelle. Cela signifie qu'il y a des limites en termes d'interaction entre le contenu web et l'application native, comme la communication directe entre les pages web et le code natif de l'application.

Absence de prise en charge des notifications :

Contrairement à WKWebView, SFSafariViewController ne permet pas d'implémenter des push notifications ou d'autres formes d'interaction directe avec le contenu web.

Navigation restreinte :

Les utilisateurs ne peuvent pas naviguer vers une nouvelle URL en modifiant l'URL dans SFSafariViewController. Pour toute nouvelle URL, il faut fermer le contrôleur actuel et en ouvrir un nouveau avec la nouvelle URL.

WKWebView

WKWebView l'alternative de SFSafariViewController peut aussi être un choix judicieux pour intégré une webview, voici ses avantages et inconvénients.

Personnalisation étendue :

• Contrôle complet : offre un contrôle complet sur l'interface utilisateur et le comportement de la webview.
• Personnalisation de l'UI : permet de personnaliser entièrement l'apparence de la webview pour qu'elle corresponde au reste de l'application.

Intégration avec l'application :

• Communication bidirectionnelle : permet une interaction plus poussée entre la webview et l'application via des scripts JavaScript.
• Contrôle de navigation : les développeurs peuvent intercepter et modifier les requêtes web, gérer les cookies et les sessions de manière personnalisée.

Complexité de Développement :

• Développement plus compliqué : nécessite plus de code et de configuration pour implémenter et gérer toutes les fonctionnalités.
• Gestion manuelle des cookies : les développeurs doivent gérer manuellement les cookies et les sessions utilisateur.

Sécurité et maintenance :

• Responsabilité accrue : les développeurs doivent implémenter des mesures de sécurité supplémentaires pour protéger contre les vulnérabilités web.
• Mises à jour manuelles : les améliorations de Safari ne se reflètent pas automatiquement, nécessitant des mises à jour de l'application.