La sécurité des applications monopages (SPA) ne fonctionne pas de la même manière que celle des sites Web

Les applications d'une seule page (SPA) gagnent rapidement du terrain en tant qu'interface facile à développer pour la fourniture de données numériques et l'engagement client.

Les applications d'une seule page (SPA) deviennent de plus en plus populaires en raison de leur facilité de développement et de leur capacité à offrir une expérience utilisateur attrayante. Cependant, les SPA présentent également des défis de sécurité uniques. Dans cet article, nous explorerons les difficultés liées à la sécurisation des SPA et discuterons d'une solution prometteuse connue sous le nom de modèle de gestionnaire de jetons.

Les sites Web traditionnels ont un seul backend qui sert le HTML et les données. L'authentification des utilisateurs s'effectue généralement sur ce serveur principal, qui est protégé par un pare-feu réseau. Cependant, les SPA sont connectés à plusieurs microservices via des API, ce qui crée une architecture plus décentralisée. Bien que cette configuration confère aux SPA leur avantage en matière de légèreté, elle introduit également des risques de sécurité importants.

L'un des principaux défis est que l'authentification des utilisateurs doit souvent avoir lieu dans le navigateur au lieu d'avoir lieu sur un serveur protégé derrière un pare-feu réseau. Cela rend les SPA vulnérables à un large éventail de types de cyberattaques, tels que le vol d'informations d'identification par script intersite (XSS). Dans cette méthode d'attaque, des acteurs malveillants peuvent injecter du code dans le navigateur capable de voler des jetons d'accès et des informations d'identification des utilisateurs, leur accordant ainsi un accès non autorisé à des données et des systèmes précieux.

Un autre défi découle du grand nombre de dépendances à l'égard de données tierces qui sont généralement connectées aux API de l'application. Des volumes élevés de connexions tierces peuvent créer un double problème.

Premièrement, les développeurs n'ont aucun contrôle sur la sécurité intégrée aux API créées par d'autres praticiens et organisations. Cela peut conduire à l'introduction de vulnérabilités dans l'application à l'insu du développeur.

Deuxièmement, la programmation dans cet environnement complexe et diversifié peut être fastidieuse en raison de la grande quantité de code détaillé et personnalisé et de paramètres d'entrée impliqués. Il peut être facile de rater une étape importante et de créer sans le savoir une faille de sécurité. De plus, des risques de sécurité cachés peuvent être introduits à mesure que l’environnement se développe et s’adapte aux demandes changeantes de l’entreprise au fil du temps.

Pour illustrer davantage les défis, comparons la configuration de la sécurisation des sites Web et des SPA.

En sécurisant les sites Web, les développeurs peuvent utiliser des sessions basées sur des cookies pour accorder aux utilisateurs l'accès à l'application Web. Le client du site Web frontal stocke des cookies sur le navigateur qui sont envoyés à un seul serveur de données principal à chaque demande d'accès de l'utilisateur. Les décisions d'autorisation peuvent être basées sur les données de session conservées en stockage afin que l'accès des utilisateurs reste sécurisé derrière le pare-feu du réseau.

Cette configuration n'est pas possible pour les SPA car une application monopage dispose d'un backend dédié. Un réseau de diffusion de contenu (CDN) transmet souvent le code au SPA via des fichiers statiques. Ces fichiers sont renvoyés via des appels API à l'application. Dans une configuration SPA, la session de l'utilisateur ne peut pas être conservée dans un cookie car il n'y a pas de stockage de données backend. Au lieu de cela, les jetons d'accès peuvent être utilisés pour appeler des API au nom de l'utilisateur authentifié.

Vulnérabilités de sécurité du SPA

Les défis de sécurité du SPA dépendent du fait que l’authentification basée sur le navigateur est vulnérable à un large éventail de types de cyberattaques. Un type de menace est le vol d’informations d’identification par script intersite (XSS). Dans cette méthode d'attaque, des acteurs malveillants injectent du code capable de voler des jetons d'accès et des informations d'identification d'utilisateur dans le navigateur pour obtenir un accès non autorisé à des données et des systèmes précieux.

Bien que XSS soit une vulnérabilité courante, ce n'est pas la seule contre laquelle les développeurs doivent se défendre. Pour rendre les choses encore plus difficiles, la correction d’une vulnérabilité en ouvre souvent de nouvelles, ce qui fait de la sécurisation des SPA un jeu sans fin d’objectifs changeants. Par exemple, utiliser les flux OAuth pour authentifier l'accès des utilisateurs ou des API avec des jetons OAuth au lieu de cookies de session semble être un bon moyen d'atténuer les attaques XSS.

Cependant, si ces jetons sont stockés dans le stockage local, les acteurs malveillants peuvent facilement accéder au stockage local et à la session pour exfiltrer les jetons. Si les jetons peuvent être actualisés, le problème est exacerbé car les attaquants peuvent y accéder même après la fin d'une session utilisateur.

Un autre exemple de problèmes involontaires pouvant survenir avec un correctif de sécurité est l'intégration de politiques de sécurité solides dans les en-têtes de politique de sécurité du contenu (CSP). Bien que cela puisse ajouter une autre couche de contrôle de sécurité, certaines sources peuvent être en mesure d'ouvrir les politiques de sécurité du contenu et de les désactiver.

En fin de compte, le navigateur est un environnement hostile lorsqu'il s'agit de se défendre contre les accès non autorisés et malveillants aux données et aux systèmes. Toute mesure de sécurité nécessite des tests minutieux et une vigilance constante pour garantir que la fermeture d'un vecteur d'attaque n'ouvre pas la voie à un autre.

Utiliser à la fois des cookies et des jetons

Une façon de sécuriser les SPA récemment développée pour protéger l'authentification des utilisateurs contre les acteurs malveillants est un modèle de gestionnaire de jetons qui fusionne la sécurité des cookies du site Web et les jetons d'accès. En mettant en œuvre une architecture de gestionnaire de jetons qui supprime l'authentification du navigateur et exploite une configuration backend pour frontend (BFF) utilisant des cookies et des jetons du même site, les organisations peuvent bénéficier des aspects légers des SPA sans sacrifier la sécurité.

Dans cette configuration, un agent OAuth hébergé en tant que composant backend se situe entre le SPA et le serveur d'autorisation. L'agent OAuth gère le flux OAuth pour le SPA et au lieu que le SPA reçoive un jeton, un cookie sécurisé HTTP uniquement est émis que le SPA peut utiliser pour accéder à ses API et microservices backend.

Un proxy OAuth hébergé dans une passerelle API hautes performances

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!