Sécurité de base

Ce que tu vas apprendre

• Garder les clés et mots de passe hors de ton dépôt.
• Traiter toute donnée venant d'un utilisateur comme potentiellement dangereuse.
• Surveiller tes dépendances et comprendre pourquoi HTTPS compte.

Ce qui est en jeu

Un site en ligne est visible de tous, y compris de personnes malveillantes. Quelques réflexes simples évitent la plupart des accidents. La sécurité ne demande pas d'être expert, mais de ne pas faire d'erreurs évidentes.

Les secrets restent hors du dépôt

Un secret est une valeur qui donne un accès : clé d'API, mot de passe de base de données, jeton. Si quelqu'un d'autre la lit, il peut agir à ta place, parfois à tes frais.

On range les secrets dans un fichier .env qui n'est jamais commité :

DATABASE_URL=postgres://utilisateur:motdepasse@serveur/recettes
NUXT_API_SECRET=une-cle-longue-et-aleatoire

Puis on l'exclut de Git :

.env

On commite à la place un fichier .env.example qui liste les noms sans les vraies valeurs. Un collègue sait ainsi quoi renseigner.

GitHub propose l'analyse de secrets (secret scanning), qui repère les clés connues dans un dépôt. Sa protection contre les push peut bloquer un envoi contenant un secret avant qu'il atteigne le dépôt. Ne compte pas dessus comme seule défense.

Ne jamais faire confiance à l'utilisateur

Tout ce que l'utilisateur tape dans un formulaire, une adresse ou un champ peut être n'importe quoi, y compris du code. Voici un commentaire sur une recette :

const commentaire = formulaire.commentaire
page.innerHTML = commentaire

Si un visiteur écrit <img src=x onerror="...">, le navigateur exécute ce code dans la page de tous les autres visiteurs. C'est une faille XSS (Cross-site scripting, script inter-site), décrite sur MDN.

La parade principale : afficher du texte comme du texte.

page.textContent = commentaire

Avec textContent, le navigateur affiche les caractères tels quels sans les interpréter comme du HTML. Les frameworks comme Vue protègent par défaut quand tu écris {{ commentaire }}. Le danger apparaît quand tu contournes cette protection, par exemple avec v-html ou innerHTML.

Valider côté serveur

Un formulaire peut être vérifié dans le navigateur pour aider l'utilisateur : champ obligatoire, format d'e-mail. Mais n'importe qui peut contourner cette vérification en envoyant la requête directement.

La règle : la validation côté navigateur sert au confort, la validation côté serveur sert à la sécurité. Vérifie toujours sur le serveur :

export default defineEventHandler(async (event) => {
  const { titre } = await readBody(event)
  if (typeof titre !== 'string' || titre.trim().length === 0 || titre.length > 100) {
    throw createError({ statusCode: 400, statusMessage: 'Titre invalide' })
  }
  // ... enregistrer la recette
})

Tu contrôles le type, la présence et la longueur avant d'utiliser la donnée. Si tu utilises une base de données, passe par les requêtes paramétrées ou la bibliothèque officielle plutôt que de coller du texte utilisateur dans une requête SQL.

Surveiller les dépendances

Ton projet utilise des dizaines de bibliothèques écrites par d'autres, avec leurs propres dépendances. Une faille découverte dans l'une d'elles devient ta faille.

npm audit interroge le registre npm et signale les vulnérabilités connues :

npm audit
npm audit fix

npm audit fix applique les corrections possibles. L'option --force peut installer des versions majeures qui cassent ton code : lis le résultat avant de l'utiliser.

D'autres habitudes aident :

Commite le fichier package-lock.json pour que tout le monde installe les mêmes versions. Installe un paquet seulement si tu en as besoin, et vérifie qu'il est maintenu.

HTTPS

HTTPS est la version chiffrée de HTTP. Les échanges entre le navigateur et le serveur ne peuvent pas être lus ni modifiés en chemin, et le visiteur sait qu'il parle bien à ton site.

Sans HTTPS, un mot de passe envoyé dans un formulaire peut être lu sur un réseau public. Les hébergeurs modernes fournissent un certificat gratuit et le renouvellement automatique. Vérifie que l'adresse de ton site commence par https://.

À retenir

• Les secrets vivent dans un .env ignoré par Git, avec un .env.example sans valeurs.
• Un secret commité est compromis : révoque-le, supprimer le fichier ne suffit pas.
• Toute donnée venue d'un utilisateur est suspecte : affiche-la comme du texte (textContent).
• La validation côté serveur est obligatoire, celle du navigateur ne sert qu'au confort.
• npm audit signale les failles connues dans tes dépendances, npm ci installe les versions du lockfile.
• HTTPS chiffre les échanges et doit être actif sur tout site en ligne.