Security by Design dans un frontend React

Le frontend n’est pas « juste l’interface » — c’est la première couche exposée aux utilisateurs, bots et attaques. Dans les projets LGPD, données sensibles et intégrations enterprise, la sécurité commence dans le JSX, pas après le deploy.

Ces pratiques viennent de dashboards compliance, portails telecom et produits avec auth et scraping.

---

1. XSS : ne pas faire confiance au HTML dynamique

dangerouslySetInnerHTML seulement avec sanitisation stricte (DOMPurify ou équivalent). Pour le contenu utilisateur, préférez un rendu structuré :

tsxCopier
// ❌ risque élevé
<div dangerouslySetInnerHTML={{ __html: userBio }} />

// ✅ markdown sanitizé ou texte brut
<ReactMarkdown>{sanitizedContent}</ReactMarkdown>

Validez aussi les URLs dans href et src — javascript: apparaît encore dans des payloads malveillants.

---

2. Tokens : mémoire vs. storage

Évitez localStorage pour les access tokens dans des SPAs exposées au XSS. Patterns plus sûrs :

• Cookies HttpOnly pour les refresh tokens (backend définit Secure et SameSite)
• Access token courte durée en mémoire (state/context)
• Rotation et révocation côté serveur

Si le produit exige localStorage, documentez le trade-off et combinez avec une CSP stricte.

---

3. Validation en couches

Le frontend valide pour l’UX ; le backend valide pour la sécurité. Ne inversez jamais cet ordre :

tsCopier
const emailSchema = z.string().email().max(254)
const parsed = emailSchema.safeParse(input)
if (!parsed.success) {
  setFieldError('email', 'E-mail invalide')
  return
}

Sur les formulaires LGPD, validez aussi consentement, finalité et champs optionnels — des données personnelles mal formatées peuvent devenir un incident.

---

4. Dépendances et surface d’attaque

npm audit ne suffit pas. Vérifiez aussi :

• Dépendances avec scripts postinstall suspects
• Scripts tiers via tag manager sans CSP
• Variables VITE_* — tout exposé côté client

Ne mettez jamais des secrets dans des variables préfixées VITE_.

---

5. Headers et politiques au edge

Même sur des SPAs statiques, configurez sur CDN ou nginx :

• Content-Security-Policy (commencez en report-only)
• X-Frame-Options ou frame-ancestors
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy restrictive

React ne protège pas contre le clickjacking — le edge le fait.

---

Conclusion

La sécurité frontend React combine rendu sûr, gestion consciente des tokens, validation en couches et politiques au edge.

Traitez chaque input comme potentiellement malveillant, chaque token comme temporaire et chaque dépendance comme un point de risque. Les produits plus sûrs passent les audits avec moins de surprises.