v1.0 Novembre 2025
6.2.2

Protection des Données
(CSRF - XSS)

La solution de cashback nouvelle génération

24 novembre 2025
Version 1.0
1

INTRODUCTION ET CONTEXTE

1.1 Objectif du Document

Ce document définit les mesures de protection mises en place sur la plateforme REWAPP contre les attaques de type Cross-Site Request Forgery (CSRF) et Cross-Site Scripting (XSS). Ces deux catégories d'attaques représentent des menaces majeures pour la sécurité des applications web et mobiles, particulièrement dans un contexte de transactions financières.

1.2 Périmètre d'Application

Les mesures de protection décrites dans ce document s'appliquent à l'ensemble des composantes de l'écosystème REWAPP :

  • Application Mobile Client - Angular + Ionic
  • Site Vitrine - Next.js
  • Dashboard Admin - React + Ant Design/MUI
  • Dashboard Partenaire - React PWA + Vite
  • API Backend - Node.js + NestJS

1.3 Références Normatives

  • OWASP Top 10 2021 : A03:2021 Injection, A07:2021 Cross-Site Scripting
  • OWASP CSRF Prevention Cheat Sheet
  • OWASP XSS Prevention Cheat Sheet
  • RGPD - Article 32 : Sécurité du traitement
  • PCI DSS v4.0 - Requirement 6.4 : Protection contre les attaques web

1.4 Classification des Risques

Matrice des Risques

Type d'Attaque Niveau de Risque Impact Potentiel Priorité
CSRF Élevé Vol de session, transactions frauduleuses, modification de données Critique
XSS Stocké Critique Vol de credentials, propagation de malware, défacement Critique
XSS Réfléchi Élevé Vol de session, phishing, redirection malveillante Haute
XSS DOM Moyen Manipulation de l'interface, vol de données Haute
2

PROTECTION CONTRE LES ATTAQUES CSRF

2.1 Définition et Mécanisme d'Attaque

Le Cross-Site Request Forgery (CSRF) est une attaque qui force un utilisateur authentifié à exécuter des actions non désirées sur une application web. L'attaquant exploite la confiance que l'application accorde au navigateur de l'utilisateur.

Scénario d'attaque typique
  1. 1

    L'utilisateur se connecte à REWAPP et obtient un cookie de session

  2. 2

    L'utilisateur visite un site malveillant (sans se déconnecter de REWAPP)

  3. 3

    Le site malveillant contient un formulaire caché qui soumet une requête vers REWAPP

  4. 4

    Le navigateur inclut automatiquement les cookies REWAPP

  5. 5

    L'action malveillante est exécutée avec les droits de l'utilisateur

2.2 Mesures de Protection Implémentées

2.2.1 Tokens CSRF (Synchronizer Token Pattern)

REWAPP utilise le pattern Synchronizer Token pour protéger toutes les requêtes modifiantes (POST, PUT, PATCH, DELETE).

Fonctionnement
  • Un token CSRF unique est généré côté serveur pour chaque session utilisateur
  • Le token est stocké dans la session serveur et transmis au client
  • Chaque requête modifiante doit inclure ce token dans le header X-CSRF-Token
  • Le serveur valide le token avant de traiter la requête

Caractéristiques du Token CSRF REWAPP

Caractéristique Valeur
Algorithme Génération aléatoire cryptographiquement sécurisée (crypto.randomBytes)
Longueur 32 bytes (256 bits) encodés en base64
Durée de vie Liée à la session (15 minutes pour access token)
Renouvellement À chaque authentification et périodiquement

2.2.2 Configuration des Cookies SameSite

Tous les cookies de session REWAPP sont configurés avec l'attribut SameSite pour limiter leur envoi aux requêtes same-origin.

Configuration des Cookies

Cookie SameSite Secure HttpOnly Domain
session_token Strict Oui Oui .rewapp.fr
refresh_token Strict Oui Oui .rewapp.fr
csrf_token Lax Oui Non .rewapp.fr
preferences Lax Oui Non .rewapp.fr
Note

L'attribut SameSite=Strict empêche l'envoi du cookie pour toute requête cross-origin, y compris les liens externes. SameSite=Lax autorise l'envoi pour les navigations top-level (liens).

2.2.3 Vérification de l'Origine (Origin/Referer Check)

En complément des tokens CSRF, le serveur vérifie les headers Origin et Referer pour s'assurer que la requête provient d'une source autorisée.

Origines Autorisées 
https://rewapp.fr
https://www.rewapp.fr
https://app.rewapp.fr
https://admin.rewapp.fr
https://partner.rewapp.fr
https://api.rewapp.fr
Comportement en cas d'échec
  • Requête rejetée avec code HTTP 403 Forbidden
  • Événement de sécurité enregistré dans les logs
  • Alerte si détection de pattern d'attaque

2.2.4 Double Submit Cookie Pattern

Pour les endpoints sensibles (transactions financières, modification de coordonnées bancaires), REWAPP implémente le Double Submit Cookie Pattern en complément.

Fonctionnement
  • Un cookie contenant une valeur aléatoire est défini
  • La même valeur doit être soumise dans le body de la requête
  • Le serveur compare les deux valeurs
  • L'attaquant ne peut pas lire la valeur du cookie (Same-Origin Policy)

2.3 Endpoints Protégés par CSRF

Endpoints Protégés

Endpoint Méthode Protection Criticité
/api/v1/auth/logout POST Token CSRF + Origin Haute
/api/v1/users/profile PUT/PATCH Token CSRF + Origin Haute
/api/v1/users/bank-account POST/PUT Token CSRF + Double Submit Critique
/api/v1/cashback/withdraw POST Token CSRF + Double Submit + 2FA Critique
/api/v1/qrcode/generate POST Token CSRF + Origin Haute
/api/v1/partners/config PUT Token CSRF + Origin Haute
/api/v1/admin/users POST/PUT/DELETE Token CSRF + Origin + Admin Auth Critique
3

PROTECTION CONTRE LES ATTAQUES XSS

3.1 Définition et Types d'Attaques XSS

Le Cross-Site Scripting (XSS) est une vulnérabilité qui permet à un attaquant d'injecter du code JavaScript malveillant dans une page web consultée par d'autres utilisateurs.

XSS Stocké

Le code malveillant est stocké sur le serveur (base de données, fichiers) et exécuté à chaque fois qu'un utilisateur consulte la page contaminée.

Exemple : Un commentaire malveillant stocké qui s'exécute pour tous les visiteurs.
XSS Réfléchi

Le code malveillant est inclus dans l'URL ou les paramètres de requête et "réfléchi" dans la réponse du serveur.

Exemple : Un lien de phishing contenant du code dans l'URL.
XSS DOM-based

Le code malveillant exploite des vulnérabilités dans le JavaScript côté client, sans passer par le serveur.

Exemple : Utilisation non sécurisée de document.location ou innerHTML.

3.2 Mesures de Protection Implémentées

3.2.1 Échappement Contextuel des Données

REWAPP applique un échappement contextuel systématique de toutes les données provenant de sources non fiables (input utilisateur, API externes, base de données).

Contextes d'Échappement

Contexte Technique d'Échappement Caractères Échappés
HTML Body HTML Entity Encoding < > & " ' /
Attributs HTML Attribute Encoding Tous sauf alphanumériques
JavaScript JavaScript Encoding Tous sauf alphanumériques
URL URL Encoding (percent-encoding) Tous sauf safe characters
CSS CSS Encoding Tous sauf alphanumériques
Implémentation Angular

Angular échappe automatiquement les données insérées dans les templates, ce qui protège contre la majorité des XSS.

Exceptions nécessitant une attention particulière
  • dangerouslySetInnerHTML : INTERDIT sauf cas validé par l'équipe sécurité
  • href avec données dynamiques : Validation obligatoire du protocole (https:// uniquement)
  • Styles dynamiques : Sanitization des valeurs CSS

3.2.2 Content Security Policy (CSP)

REWAPP implémente une politique CSP stricte pour limiter les sources d'exécution de scripts et de ressources.

CSP 
default-src 'self';
script-src 'self' https://cdn.rewapp.fr 'nonce-{random}';
style-src 'self' https://cdn.rewapp.fr 'unsafe-inline';
img-src 'self' https://cdn.rewapp.fr https://images.rewapp.fr data:;
font-src 'self' https://cdn.rewapp.fr;
connect-src 'self' https://api.rewapp.fr https://analytics.rewapp.fr;
frame-ancestors 'none';
form-action 'self';
base-uri 'self';
object-src 'none';
upgrade-insecure-requests;
Directives clés
  • script-src 'self' : Scripts uniquement depuis le domaine REWAPP
  • nonce-{random} : Scripts inline autorisés uniquement avec un nonce aléatoire
  • frame-ancestors 'none' : Protection contre le clickjacking
  • object-src 'none' : Blocage des plugins (Flash, Java)

3.2.3 Validation et Sanitization des Entrées

Toutes les données entrantes sont validées et sanitizées selon des règles strictes.

Règles de Validation

Champ Type Validation Sanitization
email string Format email RFC 5322 Trim, lowercase
nom/prénom string Alphanumérique + accents, 2-50 chars Trim, escape HTML
téléphone string Format international E.164 Trim, chiffres uniquement
montant number Positif, max 2 décimales, < 10000 Arrondi 2 décimales
commentaire string Max 500 chars Trim, escape HTML, strip tags
URL partenaire string URL valide, protocole https Validation protocole
Bibliothèques utilisées
  • class-validator : Décorateurs de validation NestJS
  • class-transformer : Transformation des données
  • DOMPurify : Sanitization HTML (quand nécessaire)
  • validator.js : Validations complémentaires

3.2.4 Headers de Sécurité HTTP

REWAPP configure les headers HTTP de sécurité sur toutes les réponses.

Headers de Sécurité

Header Valeur Objectif
X-Content-Type-Options nosniff Empêche le MIME sniffing
X-Frame-Options DENY Protection contre le clickjacking
X-XSS-Protection 1; mode=block Activation du filtre XSS navigateur (legacy)
Referrer-Policy strict-origin-when-cross-origin Contrôle des informations referer
Permissions-Policy camera=(), microphone=(), geolocation=(self) Contrôle des API sensibles
Strict-Transport-Security max-age=31536000; includeSubDomains; preload Force HTTPS (HSTS)

3.2.5 Cookies HttpOnly et Secure

Les cookies contenant des informations sensibles sont protégés par les flags HttpOnly et Secure.

HttpOnly

Le cookie n'est pas accessible via JavaScript (document.cookie), ce qui empêche le vol de session par XSS.

Secure

Le cookie n'est transmis que sur des connexions HTTPS.

3.3 Protection Spécifique par Plateforme

3.3.1 Application Mobile (Angular + Ionic)

  • Pas de WebView avec JavaScript activé pour du contenu externe
  • Validation stricte des deep links
  • Stockage sécurisé des tokens (Capacitor Secure Storage)
  • Certificate pinning pour les connexions API

3.3.2 Site Vitrine (Next.js)

  • Rendering côté serveur avec échappement automatique
  • Génération statique (SSG) quand possible pour réduire la surface d'attaque
  • Middleware de sécurité pour les headers
  • Validation des paramètres de requête

3.3.3 Dashboards (React)

  • Pas de dangerouslySetInnerHTML
  • Sanitization des données avant affichage dans les tableaux
  • Protection des formulaires d'upload
  • Validation côté client ET serveur
4

PROTECTIONS COMPLÉMENTAIRES

4.1 Protection contre l'Injection SQL

Bien que distincte de CSRF/XSS, la protection contre l'injection SQL est essentielle pour la sécurité des données.

  • Utilisation exclusive de requêtes paramétrées (Prisma ORM)
  • Pas de construction dynamique de requêtes SQL
  • Validation des types de données avant utilisation
  • Principe du moindre privilège pour les accès base de données

4.2 Protection contre l'Injection de Commandes

  • Pas d'exécution de commandes système avec des données utilisateur
  • Validation stricte des noms de fichiers pour les uploads
  • Sandbox pour le traitement des fichiers

4.3 Protection contre le Clickjacking

En complément du CSP, REWAPP implémente :

  • Header X-Frame-Options: DENY
  • Directive frame-ancestors dans CSP
  • JavaScript de frame-busting (fallback pour anciens navigateurs)

4.4 Protection des Uploads de Fichiers

Contrôles des Fichiers Uploadés

Contrôle Implémentation
Types MIME autorisés image/jpeg, image/png, application/pdf
Extension de fichier Validation whitelist (.jpg, .png, .pdf)
Taille maximale 5 MB pour images, 10 MB pour documents
Analyse antivirus Scan ClamAV avant stockage
Stockage Bucket S3 séparé, pas d'exécution
Renommage Génération UUID, suppression du nom original
Accès URLs signées avec expiration (15 min)
5

IMPLÉMENTATION TECHNIQUE REWAPP

5.1 Configuration NestJS Backend

Module de sécurité CSRF

CsrfGuard Configuration

Configuration du CsrfGuard appliqué globalement sur toutes les routes modifiantes :

  • Génération de tokens via crypto.randomBytes(32)
  • Stockage en session Redis avec TTL de 15 minutes
  • Validation du header X-CSRF-Token
  • Logging des échecs de validation

Module de sécurité XSS

Middleware global de sanitization
  • class-validator avec whitelist activé
  • Transformateur automatique des DTOs
  • Intercepteur de sanitization HTML sur les réponses
  • Validation des types stricts

5.2 Configuration Frontend React

Gestion CSRF côté client

  • Récupération du token CSRF au chargement de l'application
  • Injection automatique dans les headers Axios/Fetch
  • Renouvellement automatique après expiration
  • Gestion des erreurs 403 (refresh token CSRF)

Bonnes pratiques XSS

  • Utilisation de textContent plutôt que innerHTML
  • Bibliothèques de sanitization pour le markdown (si nécessaire)
  • Validation des URLs avant redirection
  • Pas de eval(), new Function(), ou setTimeout avec strings

5.3 Configuration Infrastructure - AWS WAF

AWS WAF (Web Application Firewall)

Règle Action Description
AWS-AWSManagedRulesCommonRuleSet Block Protection contre les attaques courantes
AWS-AWSManagedRulesSQLiRuleSet Block Protection injection SQL
AWS-AWSManagedRulesKnownBadInputsRuleSet Block Patterns malveillants connus
CustomXSSRule Block Détection patterns XSS personnalisés
RateLimitRule Block Limitation 2000 req/5min par IP
6

TESTS ET VALIDATION

6.1 Tests Automatisés

Tests unitaires CSRF

  • Validation du rejet des requêtes sans token
  • Validation du rejet des tokens invalides/expirés
  • Validation de la génération de nouveaux tokens
  • Test de la rotation des tokens

Tests unitaires XSS

  • Validation de l'échappement HTML
  • Test des différents contextes d'injection
  • Validation de la CSP
  • Test de la sanitization des inputs

Tests d'intégration

  • Scénarios complets avec tokens CSRF
  • Tests de bout en bout avec protection XSS
  • Validation des headers de sécurité

6.2 Tests de Pénétration

Outils utilisés
  • OWASP ZAP : Scan automatisé des vulnérabilités web
  • Burp Suite : Tests manuels d'injection
  • XSS Hunter : Détection de XSS blind
  • CSP Evaluator : Validation de la politique CSP
Fréquence des tests
  • Scan automatisé : Hebdomadaire
  • Test manuel : Avant chaque release majeure
  • Audit externe : Annuel (par cabinet certifié)

6.3 Checklist de Validation

Contrôles de Validation

Contrôle Fréquence Responsable Statut
Scan OWASP ZAP Hebdomadaire DevOps Automatisé
Test tokens CSRF manuels Avant release QA Sécurité Manuel
Validation CSP À chaque déploiement DevOps Automatisé
Revue de code sécurité Pull Request Développeur Senior Manuel
Audit pentest externe Annuel Prestataire externe Planifié
7

PROCÉDURES DE RÉPONSE AUX INCIDENTS

7.1 Détection des Attaques

Indicateurs de compromission CSRF

  • Pic de requêtes avec tokens invalides depuis une même IP
  • Requêtes sans header Origin depuis des sessions valides
  • Actions sensibles depuis des localisations inhabituelles

Indicateurs de compromission XSS

  • Détection de patterns d'injection dans les logs
  • Alertes WAF sur tentatives XSS
  • Rapports CSP de violations
  • Signalements utilisateurs de comportements anormaux

7.2 Procédure de Réponse

Niveau 1 - Détection Automatique
  • Alerte automatique via CloudWatch/Sentry
  • Blocage automatique de l'IP source (si pattern d'attaque)
  • Notification de l'équipe sécurité (Slack/PagerDuty)
2
Niveau 2 - Analyse
  • Investigation des logs (CloudWatch Logs Insights)
  • Identification de l'étendue de l'attaque
  • Détermination si des données ont été compromises
  • Documentation de l'incident
3
Niveau 3 - Containment
  • Blocage des IPs/ranges suspects
  • Révocation des sessions potentiellement compromises
  • Mise à jour des règles WAF si nécessaire
  • Patch de sécurité en urgence si vulnérabilité identifiée
4
Niveau 4 - Remédiation
  • Correction de la vulnérabilité
  • Tests de validation
  • Déploiement du correctif
  • Communication aux utilisateurs si nécessaire (RGPD)

7.3 Contacts d'Urgence Sécurité

Contacts d'Urgence

Rôle Contact Disponibilité
Responsable Sécurité security@rewapp.fr 24/7
DPO dpo@rewapp.fr Jours ouvrés
Équipe DevOps devops@rewapp.fr 24/7 (astreinte)
Support Niveau 2 support-l2@rewapp.fr Jours ouvrés
8

RÉCAPITULATIF ET CHECKLIST SÉCURITÉ

8.1 Synthèse des Protections

Synthèse des Protections

Menace Mesure Principale Mesure Secondaire Statut
CSRF Tokens synchronisés SameSite cookies Implémenté
XSS Stocké Échappement contextuel CSP + Sanitization Implémenté
XSS Réfléchi Validation inputs CSP + Headers Implémenté
XSS DOM Bonnes pratiques JS Revue de code En place
Clickjacking X-Frame-Options CSP frame-ancestors Implémenté
Injection SQL Requêtes paramétrées WAF Implémenté

8.2 Checklist Développeur

Avant chaque développement
  • Les entrées utilisateur sont validées côté serveur
  • Les données sont échappées selon le contexte d'affichage
  • Les requêtes modifiantes incluent le token CSRF
  • Pas d'utilisation de dangerouslySetInnerHTML
  • Les URLs dynamiques sont validées (protocole https)
  • Les cookies sensibles ont HttpOnly et Secure
  • La CSP est configurée et testée
Avant chaque déploiement
  • Scan OWASP ZAP passé sans vulnérabilité critique
  • Tests automatisés de sécurité passés
  • Revue de code sécurité effectuée
  • Headers de sécurité configurés
  • Logs de sécurité activés

8.3 Métriques de Suivi

KPIs de Sécurité

Métrique Objectif Seuil Alerte
Tentatives CSRF bloquées Monitoring > 100/heure
Violations CSP 0 en production > 10/jour
Vulnérabilités critiques 0 > 0
Temps de correction CVE < 24h critique > 48h
Score OWASP ZAP > 90/100 < 80/100
Fin du Document

Document rédigé conformément aux standards de sécurité OWASP et aux exigences RGPD/PCI DSS.

Prochaine révision : 24 mai 2026