For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/web/security.md (or send Accept: text/markdown).
Sécurité et confidentialité
Rate limits, secrets, export de données et piste d'audit.
Parcours pas à pas pour débuter
Prérequis : Lisez les deux guides pour débutants ci-dessous, terminez la configuration locale du Web et ouvrez ce monorepo à sa racine dans votre éditeur. Les paramètres Web appartiennent à apps/web/.env.local ; Next.js ne lit pas la racine .env. /dashboard dans le mode faux par défaut est une démo sans base de données ; /auth nécessite une base de données migrée.
Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.
1. Dans l'action ou la route du serveur qui lit un enregistrement appartenant à l'utilisateur, résolvez l'adhésion de l'utilisateur connecté et workspaceId actif avant d'interroger.
2. Demandez à votre agent d'ajouter un cas de membre autorisé et un refus d'espace de travail étranger pour le chemin d'enregistrement exact ; fournir les rôles et les domaines concernés.
3. La première demande doit réussir et la seconde ne doit renvoyer aucun enregistrement/accès refusé. Si la modification du seul bouton masque l'accès mais que les requêtes directes fonctionnent toujours, la limite du serveur est manquante.
Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.
Résoudre l’appartenance avant les données
La session choisit l’identité ; le serveur résout l’espace de travail actif et vérifie l’appartenance et le rôle. Chaque enregistrement détenu par un utilisateur utilise workspaceId. Un champ client, identifiant d’URL ou argument choisi par un modèle ne remplace pas cette vérification de propriété.
Les ressources marketing et les enregistrements d’administration de plateforme ont une portée explicitement plateforme ; ne créez pas un espace de travail fictif pour les inscriptions anonymes à la liste d’attente.
Appliquer la frontière aux tâches asynchrones
Les tâches, jobs, contextes d’outils, clés API, contenus, stockages et événements sortants héritent de l’espace de travail authentifié. Vérifiez les identifiants de ressources avec la propriété. Accepter un identifiant valide appartenant à un autre espace reste une erreur d’autorisation.
Écrire d’abord les tests de refus
Associez chaque lecture ou modification réussie à des tests d’utilisateur anonyme, d’autre espace de travail et de rôle insuffisant. N’exposez jamais de secrets lorsque vous diagnostiquez un refus.
Configuration et paramètres
rate-limit-runtime fournit le limiteur partagé câblé dans les routes auth, checkout, API et submission — étendez-le aux nouveaux endpoints sensibles à l'abus plutôt que d'inventer des compteurs par route. Configuration de session, cookies HTTPS-only et secrets fournisseurs restent côté serveur.
Les enregistrements d'audit du workspace (audit-runtime.ts) capturent les changements liés à la sécurité — configuration fournisseur, mises à jour de membres et rôles — et se lisent sous /settings/audit.
# Data subject export
src/data-export.ts — assembles a member's
workspace-owned records for account exportProcessus d’implémentation
Gardez les identifiants hors des logs, payloads d'erreur, propriétés analytics et valeurs d'audit — la couche d'observabilité redacte les clés connues, mais le texte libre relève de l'auteur. Résolvez l'autorisation côté serveur pour chaque lecture et écriture ; l'état d'interface est une présentation, pas une preuve.
L'export de données du compte et les demandes de suppression passent par la frontière du compte pour que les mêmes règles de propriété s'appliquent. Ne stockez que les données dont le produit a besoin.
Vérification et dépannage
Exercez le limiteur jusqu'à obtenir un 429 retentable, vérifiez que des lignes d'audit apparaissent pour les mutations censées en produire, et exportez les données d'un membre de test. Sondez une lecture inter-workspaces par release — la régression la moins chère qui compte.