Clés et sécurité des données

La plupart des vrais incidents dans les petites applications viennent de l'une de deux erreurs : une clé qui aurait dû rester sur le serveur, ou des données que n'importe qui peut lire parce qu'aucune règle n'a été définie. Cette page couvre les deux.

#Conservez les identifiants dans Secrets, jamais dans vos pages

Toute clé API, jeton ou mot de passe dont votre application a besoin va dans le panneau Secrets de la vue Backend (voir App Secrets), ou dans le formulaire d'identifiants que MeDo affiche dans la conversation lorsqu'un Skill en a besoin.

• Les valeurs sont stockées pour votre application uniquement — une clé enregistrée pour une application n'est pas partagée avec une autre.
• Les valeurs sont masquées lorsqu'elles s'affichent à nouveau, vous ne pouvez donc pas les relire depuis l'interface.
• Copier une application ne copie pas ses identifiants. Configurez-les à nouveau dans la copie.

Ne collez jamais une clé dans le contenu d'une page, dans un prompt demandant à MeDo de « mettre cette clé dans le code », ou dans quoi que ce soit qu'un visiteur peut voir.

#Deux sortes de clés, deux règles différentes

C'est pourquoi Gérer l'accès et les rôles compte : avec une clé publique dans le navigateur, vos règles sont la protection.

#Télécharger votre source

Lorsque vous téléchargez votre projet, MeDo retire la clé de service du .env à la racine du projet pour qu'elle ne voyage pas avec l'archive. L'URL publique et la clé publique restent, ce dont une exécution locale a besoin.

Deux choses à retenir :

• Remplacez ces valeurs par celles de votre propre projet lorsque vous auto-hébergez, sinon votre copie locale parle encore au backend hébergé.
• Traitez l'archive comme sensible de toute façon — elle contient la structure de votre base, vos règles et vos fonctions.

#Politique de contenu et suspension

Les applications publiées doivent suivre la politique de contenu. Une application qui la viole peut être suspendue, et elle s'affiche alors comme indisponible pour les visiteurs. Lorsque cela arrive, la raison est affichée dans le panneau de publication, avec un lien vers la politique et un bouton pour request a human review (demander une revue humaine) si vous pensez que c'était une erreur.

#Ce que MeDo ne fait pas pour vous

Soyez clair sur la frontière pour ne pas supposer une couverture que vous n'avez pas :

• Pas de scan de sécurité. MeDo ne scanne pas votre application à la recherche de vulnérabilités, de tables exposées, de règles d'accès manquantes ou de clés fuitées, et ne produit pas de rapport de sécurité.
• Pas de test d'intrusion et pas de certification de conformité de votre application.
• L'analyse de qualité n'est pas un contrôle de sécurité. Elle vérifie le fonctionnement et les erreurs de console ; elle n'essaie pas d'accès non autorisé. Voir Tester avec l'analyse de qualité IA.

#Une courte liste avant le lancement

• Chaque identifiant est dans Secrets, aucun dans le contenu des pages.
• La clé de service n'est référencée nulle part dans le frontend.
• Vous avez demandé des règles d'accès, et vous les avez vérifiées avec deux comptes de test.
• Vous vous êtes connecté en tant que second utilisateur et avez confirmé que vous ne pouvez pas voir les enregistrements du premier.
• Les champs sensibles — numéros de téléphone, adresses, notes — ne sont renvoyés qu'aux personnes qui doivent les voir.