Un effort collectif pour la sécurité
Dans le monde du développement no-code avec Bubble, la sécurité est une préoccupation majeure. Il est essentiel de comprendre que la sécurité d’une application Bubble n’est pas la seule responsabilité de la plateforme, mais un effort partagé entre plusieurs acteurs. Cette responsabilité partagée implique une collaboration active entre Bubble, Amazon Web Services (AWS) et l’utilisateur de la plateforme. Cet article détaille les rôles et responsabilités de chaque partie pour assurer une protection optimale de vos applications et des données de vos utilisateurs.
Le rôle de Bubble : Fournisseur d’outils et de sécurité de base
En tant que plateforme « Platform-as-a-Service » (PaaS), Bubble fournit l’infrastructure et les outils nécessaires au développement, au déploiement et à l’hébergement des applications web. Bubble s’engage à maintenir un environnement sécurisé en offrant des protections solides :
• Sécurité des comptes Bubble : Protection contre les accès non autorisés.
• Chiffrement des données : Les données sont chiffrées au repos et en transit, garantissant ainsi leur confidentialité.
• Authentification des utilisateurs : Mise en place de mécanismes robustes pour vérifier l’identité des utilisateurs.
• Protections au niveau de l’application : Diverses mesures sont prises pour sécuriser l’application contre les menaces.
• Disponibilité du service : Bubble assure une disponibilité constante du service, minimisant les interruptions.
• Tests d’intrusion : Des tests réguliers sont effectués pour identifier et corriger les vulnérabilités.
• Journalisation et sauvegardes : Suivi des activités et sauvegardes régulières des données.
• Protection contre les attaques DDoS : Défense contre les attaques visant à rendre un service indisponible.
• Conformité aux normes : Bubble est conforme à la norme SOC 2 Type II pour la sécurité, et met en œuvre des mesures pour respecter les lois sur la protection des données comme le RGPD
Le rôle d’Amazon Web Services (AWS) : L’infrastructure physique
AWS, en tant que fournisseur de services cloud, est responsable de la sécurité de l’infrastructure physique, du matériel, du réseau et de l’intégrité de l’environnement serveur.
Cela garantit que les fondations sur lesquelles repose la plateforme Bubble sont robustes et sécurisées.
Les responsabilités de l’utilisateur de Bubble : Le maillon essentiel de la sécurité
Bien que Bubble et AWS fournissent une base solide, la sécurité de l’application repose en grande partie sur l’utilisateur. Voici les responsabilités clés de l’utilisateur de Bubble :
• Respect des conditions d’utilisation : L’utilisateur doit comprendre et adhérer aux conditions d’utilisation de Bubble.
• Sécurité du compte Bubble : Protéger l’accès au compte avec des mots de passe robustes et en envisageant l’authentification à deux facteurs.
• Fourniture d’informations exactes : Les informations fournies à Bubble doivent être précises et à jour.
• Utilisation correcte des paramètres et outils : Comprendre et configurer correctement les paramètres de sécurité de Bubble, en particulier ceux liés à la base de données, aux pages, aux API et à la version test.
• Signalement des problèmes de sécurité : Informer rapidement Bubble en cas de découverte de vulnérabilités ou de problèmes de sécurité.
• Planification de la sécurité de l’application :
◦ Structure de la base de données : Définir des règles de confidentialité pour protéger les données sensibles.
◦ Rôles des utilisateurs : Gérer les accès aux données et aux fonctionnalités en fonction des rôles.
◦ Sécurité des pages : Contrôler les données envoyées du serveur à l’appareil de l’utilisateur.
◦ Sécurisation de l’éditeur Bubble : Restreindre l’accès à l’éditeur pour éviter les modifications non autorisées.
◦ Protection de la version Test : Supprimer les pages de test et utiliser des identifiants d’accès robustes.
◦ Sécurisation des appels API : Protéger les clés API et les informations sensibles en utilisant les paramètres privés et les en-têtes.
◦ Choix de mots de passe robustes : Définir des exigences de mots de passe complexes.
◦ Authentification à deux facteurs : Envisager la 2FA comme une mesure de sécurité supplémentaire.
◦ Éviter les données sensibles publiques : Ne pas stocker d’informations sensibles dans les valeurs par défaut des bases de données, les ensembles d’options, les workflows front-end et les réponses des appels API.
◦ Redirections côté serveur : Utiliser des redirections côté serveur pour éviter de télécharger du contenu non autorisé.
◦ Mise en œuvre de règles de confidentialité rigoureuses.
◦ Désactivation de l’API de données si elle n’est pas nécessaire.
◦ Audits de sécurité réguliers : Utiliser des outils comme Flusk Vault pour identifier et corriger les vulnérabilités.
• Conscience des risques de Sécurité : L’utilisateur doit être conscient des différentes menaces, notamment les fuites de bases de données, la divulgation de données sensibles dans le code de l’application, les accès non autorisés aux comptes et les erreurs de configuration des API.
Vulnérabilités potentielles et comment les atténuer
Il est crucial de comprendre que même avec les efforts de Bubble et AWS, des vulnérabilités peuvent exister si l’utilisateur ne prend pas les mesures nécessaires. Voici quelques points clés à surveiller :
• Vulnérabilités des plugins : Tous les plugins installés sont publics, ce qui peut exposer l’application à des risques si un plugin comporte une vulnérabilité. Mettez à jour régulièrement vos plugins et surveillez les alertes de sécurité.
• Clé API Google Maps : La clé API Google Maps est publique et doit être restreinte au domaine de l’application pour éviter les abus.
• Valeurs statiques dans les Workflows Front-End : Évitez de stocker des informations sensibles (mots de passe, etc.) dans les workflows front-end, car elles sont publiques. Utilisez plutôt des workflows back-end.
• Authentification à Deux Facteurs (2FA) : La 2FA doit être mise en œuvre côté serveur pour éviter l’interception des codes 2FA par des acteurs malveillants.
• Exposition des Workflows Back-End : Les API workflows sont publiques par défaut, désactivez cette option si elles ne sont pas nécessaires à un usage public.
• Fichier Swagger : Le fichier Swagger (OpenAPI) est public par défaut, désactivez l’accès public si vous n’en avez pas besoin.
• Sécurisation des Webhooks : Utilisez des clés API par fournisseur de webhook et privilégiez les en-têtes pour la transmission de ces clés.
• URLs des appels API : Masquez les URLs des appels API en les traitant comme des paramètres privés.
• En-têtes et Paramètres d’API : Utilisez la section « Partagés » pour les informations sensibles et cochez la case « Privé » lorsque vous utilisez les sections « Appel ».
• Corps des Requêtes API (JSON Body) : Utilisez un paramètre pour masquer les informations sensibles dans le corps de la requête.
• Réponses des appels API : Supprimez ou remplacez les valeurs sensibles des réponses API lors de l’initialisation de l’appel.
• Brute-forcing des Paramètres d’URL : Les paramètres d’URL sont publics, ne les utilisez pas pour des mesures de sécurité.
• Le Data API : Soyez très prudent si vous utilisez le Data API avec un jeton API car aucune règle de confidentialité ne s’applique. Désactivez le si vous n’en avez pas besoin.
Conclusion : Une vigilance constante
La sécurité dans l’écosystème Bubble est une responsabilité partagée. Bubble et AWS fournissent une base solide, mais l’utilisateur doit être vigilant, proactif et appliquer les bonnes pratiques. La compréhension des risques, la planification rigoureuse de la sécurité et l’utilisation des outils appropriés sont essentiels pour protéger les applications et les données des utilisateurs. Des outils d’audit automatisés, tels que Flusk Vault, peuvent grandement aider à identifier les vulnérabilités et à assurer une protection continue. En fin de compte, la sécurité d’une application Bubble repose sur la collaboration et la responsabilité de chacun.