Audit de sécurité

Demande à l’IA de passer en revue la posture de sécurité de ton application, suis les bonnes pratiques ci-dessous et conserve tes secrets dans la page Settings.

La sécurité dans Proyecta repose sur une combinaison de paramètres par défaut de la plateforme, de revues pilotées par l’IA et de quelques habitudes à adopter. Voici comment l’aborder.

Lancer un audit de sécurité

Ouvre la Command Palette (Cmd+K / Ctrl+K) et sélectionne Run Security Audit. Cela envoie une invite de sécurité complète à l’IA, qui parcourt l’intégralité de ton code source et remonte les vulnérabilités avec des résultats priorisés et des correctifs précis.

L’audit vérifie :

• Les clés API, tokens ou mots de passe codés en dur dans les fichiers sources
• Les variables d’environnement préfixées VITE_ qui exposent des secrets côté client
• L’absence de validation des entrées côté serveur sur les endpoints API
• Les pages ou endpoints API sans authentification
• Le contenu utilisateur non échappé (risques XSS)
• Les vulnérabilités des dépendances
• Les contenus mixtes ou les URLs http:// codées en dur
• L’absence de validation lors des uploads de fichiers

Tu peux également lancer un audit de sécurité manuellement depuis le chat, ou le cibler sur une zone spécifique :

• "Review my checkout flow for security issues"
• "Check the admin pages — who can access what?"
• "Look at every endpoint that writes to the database and tell me if any of them are missing authorization"

Bonnes pratiques de sécurité

Protège tes secrets

• Stocke chaque clé API, identifiant de base de données et token tiers dans la section Variables d’environnement de la page Settings
• Ne colle jamais de secrets dans les messages du chat et ne les committe pas dans le code
• Si un secret est exposé, révoque-le immédiatement auprès du fournisseur concerné et crée-en un nouveau

Limite les accès

• Implémente des permissions basées sur les rôles dans ton application ("Add admin and member roles. Only admins can access /admin pages.")
• Restreins les pages et endpoints sensibles aux utilisateurs authentifiés
• Valide toujours les entrées utilisateur côté serveur, jamais uniquement côté client

Utilise HTTPS partout

• Toutes les applications Proyecta publiées sont servies via HTTPS automatiquement
• Les certificats SSL sont provisionnés et renouvelés pour toi
• Pour les domaines personnalisés, la même règle s’applique dès que le DNS est correctement configuré

Maintiens tes dépendances à jour

• Interroge régulièrement l’IA : "Check my dependencies for known security vulnerabilities and upgrade the vulnerable ones."
• Vérifie ce que l’IA modifie — les mises à jour de dépendances incluent parfois des changements non rétrocompatibles

Audite après les changements importants

• Relance un audit après avoir ajouté de l’authentification, des paiements, des uploads de fichiers ou tout ce qui touche aux données utilisateur
• Avant de publier en production pour la première fois, effectue une vérification complète

Ce que Proyecta gère pour toi

• HTTPS et certificats pour ton sous-domaine *.proyecta.live
• L’emplacement des données de ton application — le contenu, les enregistrements et le catalogue de ton application sont stockés dans la couche de données de la plateforme Proyecta (basée sur Postgres), isolés par organisation et chiffrés au repos. Ton application publiée y accède via une publishable key (pk_pub_*) qu’il est sûr d’inclure dans la page : le serveur limite les requêtes anonymes au contenu publié uniquement, et les actions d’administration nécessitent en plus une session authentifiée avec le rôle approprié. Chaque requête est autorisée au niveau de ton organisation — une application ne peut jamais lire les données d’une autre.
• Variables d’environnement — les secrets sont stockés dans un espace dédié, synchronisés avec le backend de ton application le cas échéant, et ne sont jamais commités dans ton code. Remarque : les secrets sont visibles par les membres du workspace ayant accès au projet.
• Runtimes isolés — chaque projet s’exécute dans son propre container, ce qui évite que les problèmes de l’environnement de développement n’affectent les autres utilisateurs

Conseils

• Lance un audit avant ta première publication — une vérification complète permet de détecter les problèmes avant qu’ils ne soient en production.
• Relance l’audit après les changements importants — l’ajout d’authentification, de paiements ou d’uploads de fichiers introduit de nouvelles surfaces d’attaque.
• Cible la portée de l’audit — les audits sur des zones spécifiques sont plus rapides et plus approfondis que les analyses de l’application complète.