★ À maîtriser
📌 Tous les presets de landing page doivent respecter un overlay de bruit SVG à 0,05 d’opacité, des conteneurs aux rayons de 2 à 3 rem et des micro-interactions définies pour les boutons et les liens.
Compléments
Les presets esthétiques proposés sont :
La stack technique exigée pour la landing page est React 19, Tailwind CSS v3.4.17, GSAP 3 avec ScrollTrigger et Lucide React.
★ À maîtriser
Pour créer un CV en ligne, l’agent doit poser en un seul appel AskUserQuestion quatre questions : le nom et le titre professionnel, la direction esthétique, le parcours résumé en deux ou trois phrases, ainsi que trois expériences principales et cinq compétences clés.
La structure imposée comprend :
Compléments
📌 Le bouton « Télécharger CV » doit déclencher le téléchargement d’un PDF via un lien <a download> que l’utilisateur pourra remplacer par son véritable fichier.
★ À maîtriser
L’audit de sécurité commence par la lecture intégrale de la base de code, la modélisation de l’architecture et le repérage des points d’entrée ainsi que des flux de données.
La recherche de secrets codés en dur couvre les clés API, tokens, mots de passe, chaînes de connexion et URL de webhook, notamment les motifs sk_live_, sk_test_, sk-, pk_live_, Bearer, eyJ, ghp_, gho_, github_pat_, xoxb-, xoxp- et AKIA.
📌 Le fichier .gitignore doit exclure .env, .env.local, .env.production et .env*.local, et l’historique Git doit être vérifié pour repérer d’anciens fichiers d’environnement commités.
📌 Les secrets réservés au serveur ne doivent pas utiliser les préfixes publics NEXT_PUBLIC_, VITE_ ou REACT_APP_, notamment les clés service_role, les secrets Stripe, les clés API OpenAI ou Anthropic et les identifiants SMTP.
Compléments
📌 L’audit vérifie si les source maps sont activées en production, car elles peuvent révéler le code source original et les secrets intégrés au client.
📌 L’application doit échouer rapidement lorsque des variables d’environnement requises manquent, plutôt que de fonctionner avec des valeurs indéfinies ou des valeurs par défaut non sécurisées.
★ À maîtriser
Pour chaque table du schéma public, l’audit vérifie que la sécurité au niveau des lignes (RLS) est activée, y compris pour les tables créées par migration ou dans l’éditeur SQL.
Chaque table protégée par RLS doit posséder une policy SELECT autorisant les lectures souhaitées afin que celles-ci ne renvoient pas silencieusement des résultats vides ; une policy INSERT n’est nécessaire que si des insertions doivent être autorisées.
Les policies INSERT et UPDATE doivent inclure des clauses WITH CHECK pour empêcher l’usurpation d’un user_id à l’insertion et le transfert de propriété à la mise à jour.
Les policies RLS doivent fonder l’identité sur auth.uid() et non sur auth.jwt()->'user_metadata', car les métadonnées utilisateur peuvent être modifiées par l’utilisateur authentifié.
La clé service_role, qui contourne le RLS, ne doit jamais être utilisée côté client ni importée dans des composants ; son usage doit rester côté serveur et être réellement nécessaire.
Compléments
Si Supabase Storage est utilisé, l’audit doit vérifier que les buckets disposent de policies RLS, car ils sont privés par défaut.
L’audit recherche les requêtes SQL brutes construites par concaténation ou template literals plutôt que par paramètres, y compris les appels .rpc() et les usages de pg ou postgres.js.
Les fonctions de base de données SECURITY DEFINER doivent être examinées pour détecter une exposition de données ou un contournement du RLS, car elles s’exécutent avec les privilèges de leur créateur.
📌 L’audit vérifie que le middleware d’authentification existe, s’exécute sur les routes protégées et possède un matcher couvrant tous les chemins nécessaires.
📌 Le refus par défaut protège les routes par une liste blanche de routes publiques, tandis que la protection par exception s’appuie sur une liste noire de routes protégées ; le refus par défaut est plus sûr, car les nouvelles routes sont automatiquement protégées.
★ À maîtriser
Les opérations sensibles côté serveur d’une application Supabase doivent utiliser supabase.auth.getUser(), qui valide le JWT auprès des serveurs Supabase, plutôt que supabase.auth.getSession(), qui lit le JWT local sans le vérifier.
Les jetons de session doivent être stockés dans des cookies httpOnly plutôt que dans localStorage ou sessionStorage, accessibles au JavaScript de la page, y compris aux charges XSS.
Chaque route API qui traite des données utilisateur doit vérifier l’authentification avant tout traitement.
Compléments
La route /auth/callback doit échanger correctement les codes d’authentification contre des sessions, traiter les erreurs et ne pas exposer les jetons dans les URL ou les journaux.
Une implémentation OAuth doit valider les URL de callback, utiliser le paramètre state pour la protection CSRF et gérer les jetons de manière sécurisée.
Les jetons de réinitialisation de mot de passe doivent expirer, être à usage unique et être transmis de manière sécurisée.
getUser valide le JWT auprès de Supabase ; getSession lit seulement le JWT local.
★ À maîtriser
Toutes les routes API et actions serveur doivent valider leurs entrées côté serveur à l’aide d’une bibliothèque de validation par schéma, telle que Zod, Yup, Valibot ou ArkType.
L’identité utilisée pour les opérations d’écriture doit toujours être dérivée de la session authentifiée ou du JWT, jamais d’un champ userId fourni dans le corps de la requête.
Le contenu utilisateur rendu en HTML doit être nettoyé contre les attaques XSS, notamment lors de l’utilisation de dangerouslySetInnerHTML, v-html, [innerHTML] ou de template literals non échappés.
Compléments
Les opérations qui modifient l’état doivent utiliser POST, PUT, PATCH ou DELETE plutôt que GET, car des images, le préchargement de liens ou des extensions peuvent déclencher des requêtes GET sans intention de l’utilisateur.
Les erreurs renvoyées au client ne doivent pas révéler de détails internes tels que les traces de pile, erreurs SQL, chemins de fichiers ou noms de variables d’environnement.
Une application qui reçoit des webhooks doit en valider la signature avant de traiter les événements, afin d’empêcher l’envoi de faux événements à son endpoint.
★ À maîtriser
📌 Un lockfile, tel que package-lock.json, pnpm-lock.yaml, yarn.lock ou bun.lockb, doit être commité pour éviter que npm install ne récupère silencieusement des versions différentes, potentiellement compromises.
Compléments
L’audit du gestionnaire de packages doit être exécuté avec npm audit, pnpm audit, yarn audit ou bun audit, et ses vulnérabilités doivent être rapportées par niveau de sévérité.
Les packages installés doivent être examinés si leurs téléchargements sont anormalement peu nombreux, s’ils viennent d’être publiés ou si leurs noms ressemblent peu à ceux de packages connus, car des noms halluciné́s ou similaires peuvent cacher des malwares.
Les packages obsolètes doivent être repérés, en particulier ceux qui ont des CVE connues et ceux des domaines de l’authentification, de la cryptographie et des frameworks.
Les packages inscrits dans package.json qui ne sont importés nulle part dans le code doivent être repérés, car toute dépendance inutilisée constitue une surface d’attaque inutile.
Sans lockfile, npm install peut récupérer des versions différentes, potentiellement compromises.
★ À maîtriser
Les routes API qui appellent des services externes payants, comme OpenAI, Anthropic, Stripe ou des fournisseurs d’e-mail et de SMS, doivent avoir une limitation de débit pour prévenir les dépenses causées par le spam d’un endpoint.
Les endpoints de connexion, d’inscription, de réinitialisation de mot de passe et d’OTP doivent avoir une limitation de débit contre les attaques par force brute et le bourrage d’identifiants.
La limitation de débit doit être appliquée côté serveur et s’appuyer sur un stockage fiable comme Redis ou Upstash, plutôt que sur un stockage en mémoire ou un simple debouncing frontend.
Compléments
📌 Les routes API destinées uniquement au frontend de l’application doivent restreindre les en-têtes CORS aux domaines de l’application, en évitant Access-Control-Allow-Origin: * sur les endpoints sensibles.
📌 Access-Control-Allow-Credentials ne doit être activé qu’avec des origines CORS spécifiques et non avec une origine joker.
★ À maîtriser
📌 Le type et la taille des fichiers téléversés doivent être validés côté serveur, et le type MIME doit être vérifié plutôt que de se fier uniquement à l’extension, qu’un utilisateur peut modifier.
📌 Les fichiers téléversés doivent avoir des contrôles d’accès adaptés à leur usage : les fichiers publics, comme les photos de profil, nécessitent des politiques différentes des fichiers privés, comme les documents.
Compléments
📌 Les fichiers téléversés ne doivent pas pouvoir être exécutés sur le serveur, et leurs répertoires ne doivent pas se trouver dans le chemin exécutable de la racine web.
Les fichiers publics et les fichiers privés exigent des politiques d’accès différentes.
★ À maîtriser
Le SaaS de facturation doit proposer un tableau de bord affichant le nombre total de factures, le montant facturé, le montant payé et le montant en attente.
La création d’une facture doit permettre de choisir un client, de saisir les dates d’émission et d’échéance et de gérer des lignes comprenant une description, une quantité et un prix unitaire.
Les factures doivent calculer automatiquement une TVA de 18 %, afficher les montants en FCFA arrondis à l’entier et proposer l’enregistrement comme brouillon ou l’envoi.
Compléments
Le SaaS doit permettre de gérer les clients avec leur nom, leur e-mail, leur téléphone et leur adresse, ainsi que les paramètres de l’entreprise comprenant son nom, son adresse et son logo.
Les factures doivent pouvoir avoir les statuts brouillon, envoyée, payée ou en retard.
La landing page d’iziFacture doit présenter des offres Gratuit avec 5 factures par mois et 1 utilisateur, Pro illimitée à 5 000 FCFA par mois, et Business multi-utilisateurs à 15 000 FCFA par mois, avec le plan Pro mis en avant.
🔄 Le parcours de développement suit ces étapes :
Les montants de l’application doivent être affichés en FCFA et les dates au format jour/mois/année.
L’interface doit être responsive, avec une barre latérale sur ordinateur et un menu hamburger sur mobile.
La page de factures doit proposer des filtres par statut, une recherche par nom de client et l’ouverture du détail d’une facture ; le détail doit permettre de changer le statut, modifier ou supprimer la facture après confirmation.
Fonctionnalités et design → interactions locales → Supabase et tests → authentification → landing page → audit et déploiement.
★ À maîtriser
📌 Le projet doit être analysé avant toute décision de design en examinant sa structure, ses fichiers de style et de thème, ses composants, ses pages, son package.json, ses assets et ses polices.
Compléments
La stratégie de design dépend de l’état du projet : un design system existant doit être conservé et amélioré, un projet existant incohérent doit recevoir un système cohérent, et un projet sans code appelle des questions de cadrage sur le produit, le style, les pages, les inspirations et le CTA.
Les interfaces doivent assurer des interactions accessibles avec des libellés pour les icônes, un focus visible et un contraste suffisant.
Les formulaires doivent afficher des libellés au-dessus des champs, un état de focus visible et des erreurs sous les champs plutôt qu’une alerte globale.
Les tableaux doivent fournir un état de survol distinctif ; sur mobile, les tableaux doivent devenir des cartes et la barre latérale doit se replier derrière un menu hamburger.
Teste tes connaissances sur Sécurité et conception du SaaS avec 35 questions à choix multiples et corrections détaillées.
1. Un client demande une landing page pour sa marque. Que doit faire l’agent avant de la construire ?
2. Une équipe prépare un preset de landing page et doit vérifier ses règles visuelles fixes. Quelle configuration respecte ces exigences ?
Mémorisez les concepts clés de Sécurité et conception du SaaS avec 84 flashcards interactives.
Quelles informations l’agent doit-il demander en un appel pour une landing page ?
Le nom et l’objectif de la marque, une direction esthétique, trois arguments de vente et l’action attendue des visiteurs.
Quelle opacité doit avoir l’overlay de bruit SVG des presets ?
0,05.
Quels rayons doivent avoir les conteneurs des presets ?
De 2 à 3 rem.
Importe ton cours et l'IA génère fiches, QCM et flashcards en 30 secondes.
Générateur de fiches