QCM : Sécurité et conception du SaaS (35 questions)

Explication

Le processus exige un seul appel regroupant quatre questions : nom et objectif de la marque, direction esthétique, trois arguments de vente et action souhaitée des visiteurs. Les appels multiples fractionnent le processus, les compétences ne remplacent pas les arguments de vente et l’action attendue ne doit pas être omise.

Explication

Chaque preset doit conserver un overlay de bruit SVG à 0,05 d’opacité, des rayons de conteneurs de 2 à 3 rem et des micro-interactions pour les boutons comme pour les liens. Une opacité de 0,5 ou des rayons de 1 à 2 rem modifient les paramètres prescrits, tandis que l’omission des liens rend la configuration incomplète.

Explication

La structure associe une navbar flottante et un hero plein écran aux sections Fonctionnalités, Philosophie, Protocole et Adhésion ou Tarification, avant le pied de page. « À propos » appartient à une autre structure, les cartes de compétences ne remplacent pas les cartes Protocole, et la navbar prescrite est flottante.

Explication

La création du CV commence par un seul appel AskUserQuestion portant sur quatre éléments : identité professionnelle, direction esthétique, bref parcours, puis trois expériences et cinq compétences clés. Deux expériences ne respectent pas le nombre demandé, l’action des visiteurs relève d’une landing page et le recueil doit se faire en un seul appel.

Explication

Après la navbar et le hero, le CV présente À propos, Expérience, Compétences, Formation et Contact, puis le pied de page. Philosophie, Protocole et Tarification sont des sections associées à une landing page, et ne remplacent pas celles du CV.

Explication

La découverte commence par la lecture intégrale du code, la modélisation de l’architecture et le repérage des points d’entrée et des flux. Se limiter aux routes omet d’autres entrées, corriger avant d’avoir cartographié le système inverse la démarche, et examiner la configuration seule ne suffit pas.

Explication

Les motifs ghp_ et Bearer font partie des chaînes à rechercher, au même titre que d’autres préfixes de clés et de jetons. NEXT_PUBLIC_ relève des préfixes de variables publiques, un nom de fonction n’est pas en soi un secret, et limiter la recherche aux mots de passe ignore les clés et jetons.

Explication

L’audit vérifie l’exclusion de .env, .env.local, .env.production et .env*.local, ainsi que l’historique Git, où un ancien fichier commité peut encore exposer des secrets. Ignorer l’historique laisse ce risque intact, tandis qu’une vérification limitée des exclusions manque des variantes demandées.

Explication

Les secrets réservés au serveur, notamment les secrets Stripe, ne doivent pas employer les préfixes publics des frameworks; avec Vite, il faut donc éviter VITE_. NEXT_PUBLIC_ et REACT_APP_ sont également des préfixes publics, et le stockage en variable d’environnement ne rend pas sûre une exposition au client.

Explication

L’audit vérifie l’activation de RLS sur chaque table du schéma public, y compris celles créées par migration ou dans l’éditeur SQL. L’origine de la table ne garantit pas sa protection, et une policy ne remplace pas l’activation de RLS.

Explication

Les policies INSERT et UPDATE doivent inclure WITH CHECK afin de contrôler les valeurs autorisées, notamment le user_id à l’insertion et le transfert de propriété à la mise à jour. Une vérification de lecture ne contrôle pas les données insérées, et une policy UPDATE seule ne protège pas l’insertion.

Explication

auth.uid() fournit la source d’identité fiable pour les policies RLS; les métadonnées utilisateur peuvent être modifiées par l’utilisateur authentifié. Un champ de profil transmis ou modifiable par le client ne corrige pas ce problème, et user_metadata n’est pas une preuve d’identité fiable.

Explication

L’audit vérifie à la fois l’existence et l’exécution du middleware sur les routes protégées, ainsi que la couverture de tous les chemins nécessaires par le matcher. Se fier à la seule existence du middleware, viser les routes publiques ou supposer une protection automatique ne répond pas à cette exigence.

Explication

Avec le refus par défaut, une liste blanche désigne les routes publiques et les nouvelles routes sont protégées automatiquement. Une liste noire exige d’ajouter les routes protégées, tandis qu’une liste blanche de routes protégées inverse le mécanisme décrit.

Explication

Pour une opération sensible côté serveur, getUser valide le JWT auprès des serveurs Supabase. getSession lit le jeton local sans le vérifier; l’attribuer à getUser ou prétendre qu’il valide le jeton à distance confond les deux méthodes.

Explication

Les cookies httpOnly ne sont pas accessibles au JavaScript de la page, contrairement aux stockages local et de session ainsi qu’aux cookies accessibles aux scripts. Le choix du stockage local ou de session repose donc sur la confusion documentée concernant leur exposition au JavaScript.

Explication

Chaque route API qui traite des données utilisateur doit vérifier l’authentification avant tout traitement. La repousser après une lecture ou une erreur inverse l’ordre requis, et la validation des entrées ne remplace pas cette vérification.

Explication

Une route API doit valider ses entrées côté serveur à l’aide d’une bibliothèque de validation par schéma. La validation du formulaire relève de l’expérience utilisateur, et un simple contrôle de type ne remplace pas cette validation.

Explication

Pour une opération d’écriture, l’identité fiable est celle dérivée de la session authentifiée ou du JWT. Le champ « userId » fourni par le client peut être falsifié; le combiner avec la session ne le rend pas fiable.

Explication

Le contenu utilisateur rendu en HTML doit être nettoyé contre les attaques XSS, notamment avec « dangerouslySetInnerHTML ». L’authentification de l’auteur ne neutralise pas son contenu, et un nettoyage après affichage intervient trop tard.

Explication

Un lockfile commité fixe les versions résolues et évite que npm install ne récupère silencieusement des versions différentes. Le manifeste décrit les dépendances, tandis qu’un audit recherche des vulnérabilités sans fixer leurs versions.

Explication

Un nombre de téléchargements anormalement faible, une publication récente et un nom ressemblant à celui d’un paquet connu sont des signaux qui justifient un examen. La proximité du nom ne prouve pas la légitimité, et l’âge ou la popularité pris isolément ne règle pas la question.

Explication

La limitation de débit des routes qui sollicitent des services externes payants aide à empêcher qu’un spam d’endpoint ne fasse exploser la facture. Limiter les seules routes de connexion néglige les appels payants, tandis que CORS et les contrôles de fichiers répondent à d’autres risques.

Explication

Les endpoints d’authentification doivent être limités en débit pour contrer la force brute et le bourrage d’identifiants. Réserver cette mesure aux appels payants confond deux catégories de routes, et CORS ou la validation MIME ne freinent pas ces tentatives.

Explication

Une limitation côté serveur appuyée par un stockage fiable comme Redis ou Upstash conserve mieux les compteurs qu’un stockage mémoire réinitialisé au déploiement. Allonger la durée mémoire ne supprime pas cette réinitialisation, et un délai anti-rebond frontend ne constitue pas une protection serveur fiable.

Explication

Le serveur doit vérifier le type et la taille du fichier, et le type MIME est plus fiable que l’extension, que l’utilisateur peut modifier. Se fier à « .jpg » laisse passer un contenu trompeur, une validation frontend peut être contournée, et ignorer la taille omet une vérification requise.

Explication

Les permissions doivent correspondre à l’usage : une photo publique et un document privé appellent des politiques d’accès différentes. Traiter les deux catégories comme publiques ou privées ignore cette distinction, et l’extension ne détermine pas le niveau de confidentialité.

Explication

Le tableau de bord réunit le nombre total de factures et les trois indicateurs financiers : montants facturé, payé et en attente. Le nombre de clients relève de la gestion des clients, le nombre de factures payées n’est pas le montant payé, et les deux autres réponses omettent un indicateur requis.

Explication

La création d’une facture prévoit le choix d’un client, les dates d’émission et d’échéance, et des lignes composées d’une description, d’une quantité et d’un prix unitaire. Saisir toutes les coordonnées du client, remplacer l’échéance par la date de paiement ou ne saisir qu’un montant total confond ces éléments.

Explication

La facture applique automatiquement une TVA de 18 %, affiche les montants en FCFA arrondis à l’entier et peut être enregistrée comme brouillon ou envoyée. Un taux de 20 %, l’affichage avec décimales ou l’absence d’enregistrement en brouillon ne respecte pas cette configuration.

Explication

Le parcours commence par les fonctionnalités inspirées des captures, puis les rend interactives avec des données locales avant d’ajouter Supabase et les tests. L’authentification et la landing page suivent, puis vient le contrôle de bout en bout avant le déploiement et un nouveau test ; les autres parcours déplacent ces étapes.

Explication

La page de factures comprend des filtres par statut, une recherche par nom de client et l’accès au détail ; celui-ci permet de changer le statut, de modifier ou de supprimer après confirmation. La recherche par montant substitue un autre critère, tandis que la suppression sans confirmation omet une protection prévue.

Explication

L’analyse préalable porte sur l’ensemble du projet, notamment sa structure, ses styles, ses composants, ses pages, son package.json, ses assets et ses polices. Commencer par la palette inverse l’ordre, ignorer styles et ressources rend l’analyse incomplète, et s’en tenir au package.json ne suffit pas.

Explication

Un projet existant mais incohérent appelle la création d’un système de design cohérent, en tenant compte de ce qui mérite d’être conservé. Les questions de cadrage visent un projet sans code, les retouches seules supposent un système déjà établi, et maintenir toutes les incohérences empêche l’harmonisation.

Explication

Une policy SELECT doit autoriser les lectures souhaitées afin qu’elles ne renvoient pas silencieusement des résultats vides; une policy INSERT n’est requise que si des insertions sont autorisées. La policy INSERT ne règle pas les lectures, et l’activation de RLS sans policy SELECT ne les autorise pas.