Guide de Sécurité Mendix

Authentification (Token vs Session), SSO et Protection contre les Attaques

Table des Matières

1. Modes d'Authentification
2. Authentification par Session (Par défaut Mendix)
3. Authentification par Token (API/Mobile)
4. Integration SSO (Single Sign-On)
5. Sécurité : Protection contre les Attaques
6. Checklist de Sécurité Mendix

1. Modes d'Authentification

Mendix supporte deux principaux modes d'authentification, chacun adapté à des cas d'usage
spécifiques.

Comparaison Token vs Session

Critère Session (Cookie) Token (JWT/Bearer)

Type Stateful (serveur garde la session) Stateless (auto-contenu)
Stockage Cookie HTTP (automatique) Header Authorization ou
LocalStorage
Cas d'usage Applications web traditionnelles API REST, applications mobiles,
SPA
Scalabilité Moins scalable (état serveur) Très scalable (sans état)
Sécurité CSRF Vulnérable (besoin protection) Protégé naturellement
Expiration Timeout configurable serveur Exp claim dans le token (JWT)
2. Authentification par Session (Par défaut Mendix)

Comment ça fonctionne
1. L'utilisateur se connecte via la page de login
2. Mendix crée une session côté serveur et stocke un identifiant de session
3. Un cookie contenant l'ID de session est envoyé au navigateur
4. Chaque requête inclut automatiquement ce cookie
5. Le serveur valide la session à chaque requête

Configuration dans Mendix

• App Settings → Security → Security level: Production
• Navigation → Sign-in page automatique
• Runtime Settings → Session timeout: 600 secondes (10 min par défaut)

Sécurisation des Cookies

Ajoutez ces configurations dans votre environnement Mendix Cloud ou [Link] :

• HttpOnly: true (empêche l'accès JavaScript aux cookies)

• Secure: true (cookies transmis uniquement en HTTPS)
• SameSite: Strict ou Lax (protection CSRF)

Dans Mendix Cloud, allez dans Environments → Details → Network → Cookie settings
3. Authentification par Token (API/Mobile)

Pourquoi utiliser les Tokens ?

• Applications mobiles natives (iOS, Android)
• APIs REST consommées par des tiers
• Microservices et architectures distribuées
• Single Page Applications (SPA)

Implémentation dans Mendix

Option 1: Module Community Commons
6. Installez le module Community Commons depuis le Marketplace
7. Utilisez l'action GenerateHMACSHA256Hash pour créer des tokens
8. Stockez les tokens dans une entité personnalisée (ex: AuthToken)

Option 2: Module OIDC (Recommandé pour JWT)

9. Installez OIDC SSO depuis le Marketplace
10. Configure pour générer et valider des JWT tokens
11. Supporte les standards OAuth 2.0 et OpenID Connect

Architecture Token-Based
12. Créer un microflow API_Login
○ Paramètres: Username (String), Password (String)
○ Valider les credentials
○ Générer un token unique (UUID ou JWT)
○ Stocker: Token, User, ExpirationDate, CreatedDate
○ Retourner le token au client

13. Créer un microflow API_ValidateToken

○ Paramètre: Token (String)
○ Retrieve from database: [Token = $Token]
○ Vérifier expiration: [ExpirationDate > [%CurrentDateTime%]]
○ Retourner User object ou null

14. Publier les REST endpoints

○ POST /api/login → API_Login
○ GET /api/resource → API_ValidateToken + logique métier

Exemple de Requête Client

Login:
POST [Link] Content-Type: application/json
{ "username": "user@[Link]", "password": "secret123" }

Réponse:
{ "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "expiresIn": 3600 }

Requêtes suivantes:
GET [Link] Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

4. Intégration SSO (Single Sign-On)

Le SSO permet aux utilisateurs de s'authentifier une seule fois pour accéder à plusieurs
applications.
Protocoles Supportés par Mendix
• SAML 2.0 (Azure AD, Okta, Google Workspace)
• OpenID Connect (OIDC) (Auth0, Keycloak, Azure AD B2C)
• OAuth 2.0 (APIs tierces)
Implémentation SAML 2.0
Étape 1: Installation du Module
15. Ouvrez le Mendix Marketplace
16. Recherchez et installez SAML
17. Acceptez les dépendances (Community Commons, Mx Model Reflection)

Étape 2: Configuration Mendix

18. Dans App Settings → Security:
○ Security level: Production
○ Enable SAML authentication

19. Dans le module SAML:

○ Allez dans SAML → Configuration
○ Créez une nouvelle configuration IdP (Identity Provider)
○ Uploadez le metadata XML de votre IdP (Azure AD, Okta, etc.)

20. Téléchargez le metadata Mendix:

○ URL: [Link]
○ Fournissez ce fichier à votre administrateur IdP

Étape 3: Configuration Azure AD (Exemple)

21. Dans Azure Portal → Azure Active Directory → Enterprise Applications
22. New application → Create your own application
23. Nom: "Mendix ClubHub" → Integrate any other application (Non-gallery)
24. Single sign-on → SAML
 25. Upload le metadata Mendix ou configurer manuellement:
○ Identifier (Entity ID): [Link]
○ Reply URL: [Link]
○ Sign on URL: [Link]
26. Téléchargez le Federation Metadata XML d'Azure
27. Importez ce XML dans Mendix SAML Configuration

Étape 4: Mapping des Utilisateurs

Configurez le mapping des attributs SAML vers les entités Mendix:

• Email → Person/Name
• FirstName → Person/FirstName
• LastName → Person/LastName
• Roles → Person/UserRoles

Implémentation OpenID Connect (OIDC)

28. Installez le module OIDC SSO depuis Marketplace
29. Configurez le Client ID, Client Secret, Discovery URL
30. Exemple pour Auth0:
○ Discovery URL: [Link]
configuration
○ Redirect URI: [Link]

5. Sécurité : Protection contre les Attaques

Mendix intègre de nombreuses protections par défaut, mais certaines configurations et bonnes
pratiques sont essentielles.

5.1 Protection contre IDOR (Insecure Direct Object Reference)

Qu'est-ce que IDOR ?
Un attaquant modifie un ID dans une URL pour accéder aux données d'un autre utilisateur.
Exemple: /api/user/123 → /api/user/124

Protection dans Mendix

• 1. Entity Access Rules (Obligatoire)

Dans le Domain Model, pour chaque entité:

○ Clic droit sur l'entité → Access rules
○ Créez une règle pour le rôle "Person":
 Propriété Valeur
Allow create Yes (pour l'inscription)
Allow delete No (sauf si nécessaire)
XPath constraint [id = '[%CurrentUser%]']
Member rights Read/Write seulement sur les attributs autorisés

⚠️Cette contrainte XPath garantit que chaque utilisateur ne peut accéder qu'à ses propres
données !

• 2. Validation dans les Microflows

Dans vos microflows, ajoutez toujours des vérifications:

// Microflow: ACT_UpdatePerson // Paramètre: PersonId (Long) 1. Retrieve Person by ID 2.

Decision: $Person/id = $CurrentUser/id ? - No → Show error "Unauthorized access" → End
- Yes → Continue with update

5.2 Protection contre SQL Injection

Bonne nouvelle : Mendix est immunisé !
Mendix utilise un ORM (Object-Relational Mapping) qui génère automatiquement des requêtes
SQL paramétrées. Les injections SQL sont pratiquement impossibles si vous suivez ces règles :

• ✅ TOUJOURS utiliser XPath ou Retrieve actions

• ❌ JAMAIS construire des requêtes SQL manuellement

Exemple sécurisé (XPath)

// Retrieve Person by email (safe) Retrieve from database Entity: Person XPath: [Email =
$SearchEmail] // Mendix génère automatiquement: // SELECT * FROM person WHERE email
= ? (paramétré)

⚠️Danger : Java Actions avec SQL brut

Si vous devez absolument écrire du SQL dans une Java Action, utilisez TOUJOURS
PreparedStatements:

// ❌ UNSAFE String sql = "SELECT * FROM person WHERE email = '" + userInput + "'"; // ✅
SAFE String sql = "SELECT * FROM person WHERE email = ?"; PreparedStatement stmt =
[Link](sql); [Link](1, userInput);
5.3 Protection contre XSS (Cross-Site Scripting)
Qu'est-ce que XSS ?
Le XSS (Cross-Site Scripting) est une faille qui permet à un attaquant d'injecter du code
JavaScript malveillant dans une page web consultée par d'autres utilisateurs. Ce code s'exécute
dans le navigateur de la victime à son insu.

Type Description Exemple

Reflected Le script est dans l'URL et reflété immédiatement ?name=<script>alert(1)</script>
Stored Le script est sauvegardé en base de données Commentaire malveillant stocké
DOM-based Le script manipule directement le DOM Via innerHTML non filtré

Mendix est-il protégé automatiquement ?

Composant Protégé auto ?
Widgets standard Mendix ✅ Oui — échappement automatique
Attributs texte affichés via Text widget ✅ Oui
HTML snippet widget ❌ Non — dangereux
Java Actions avec HTML ❌ Non
Contenu dynamique via innerHTML ❌ Non
Expressions Mendix non échappées ⚠️Dépend

Protection dans Mendix

• 1. Encodage automatique par défaut

Mendix encode automatiquement toutes les sorties HTML. Exemple:

Input: <script>alert('XSS')</script> Output affiché: &lt;script&gt;alert('XSS')&lt;/script&gt;

• 2. Attention au HTML Snippet Widget ⚠️

Le widget "HTML Snippet" affiche du HTML brut sans encodage. Ne JAMAIS l'utiliser
avec du contenu utilisateur non validé !

○ ❌ Mauvais: HTML Snippet avec $Person/Bio (saisie utilisateur)

○ ✅ Bon: Text Area widget qui encode automatiquement

• 3. Validation des entrées

Utilisez des validations côté serveur dans les microflows:

// Valider qu'un champ ne contient pas de HTML if contains($Person/Bio, '<script>') then Show
error "Invalid characters detected" else Save
 • 4. Content Security Policy (CSP)

Dans Mendix Cloud, configurez les headers CSP:

○ Environments → Details → HTTP Headers
○ Ajoutez: Content-Security-Policy: default-src 'self'; script-src 'self'

5.4 Protection contre CSRF (Cross-Site Request Forgery)

Qu'est-ce que CSRF ?
Un site malveillant force votre navigateur à effectuer une action non autorisée sur votre
application.

Protection dans Mendix

• 1. Token CSRF automatique (Session-based)

Mendix génère automatiquement des tokens CSRF pour toutes les requêtes en mode session.
Aucune action requise !

• 2. SameSite Cookie Attribute

Configurez vos cookies en mode Strict ou Lax:

Mendix Cloud → Environments → Cookie settings → SameSite: Strict

• 3. Vérification Origin/Referer

Pour les APIs, validez l'origine des requêtes dans un microflow:

// Dans un Before microflow d'un REST endpoint $Origin = $HttpRequest/getHeader('Origin') if
$Origin != '[Link] then Return 403 Forbidden

5.5 Protection contre les Attaques par Force Brute

• 1. Limitation de tentatives (Rate Limiting)

Créez une entité LoginAttempt:

Attributes: - Username (String) - AttemptTime (DateTime) - IPAddress (String) - Success
(Boolean)

Dans le microflow de login:

1. Retrieve failed attempts for $Username in last 15 minutes 2. If count >= 5 then Show error
"Too many failed attempts. Try again in 15 minutes" End 3. Else continue with login 4. Log
attempt (success or failure)

• 2. CAPTCHA
 ○ Installez le module Google reCAPTCHA depuis Marketplace
○ Ajoutez le widget reCAPTCHA sur votre page de login
○ Validez le token reCAPTCHA avant d'accepter le login

• 3. Politique de mots de passe forts

Dans App Settings → Security → Password policy:

○ Minimum length: 12 caractères
○ Require digit: Yes
○ Require mixed case: Yes
○ Require symbol: Yes

5.6 Autres Bonnes Pratiques

Protection contre les Clickjacking
Ajoutez le header X-Frame-Options:
Mendix Cloud → HTTP Headers → X-Frame-Options: DENY

HTTPS Obligatoire
Activez la redirection automatique HTTP → HTTPS dans Mendix Cloud:
• Environments → Details → Network → Force HTTPS: Yes

Logging et Monitoring
• Activez les logs de sécurité dans App Settings → Logging
• Loguez toutes les tentatives de connexion (succès et échecs)
• Surveillez les patterns d'accès suspects
6. Checklist de Sécurité Mendix

Configuration de Base
• ☐ Security level mis en Production
• ☐ Password policy configurée (min 12 chars, mixte, symboles)
• ☐ Session timeout configuré (10-30 minutes)
• ☐ Cookies sécurisés (HttpOnly, Secure, SameSite)

Entity Access Rules

• ☐ Toutes les entités ont des Access Rules définies
• ☐ XPath constraints pour limiter l'accès aux données propres
• ☐ Member access configuré (Read/Write uniquement sur attributs nécessaires)

Microflows et Logic
• ☐ Validation de propriété dans les microflows critiques
• ☐ Vérification $CurrentUser avant modifications
• ☐ Utilisation exclusive de XPath/Retrieve (pas de SQL brut)
• ☐ Input validation pour tous les champs utilisateur

Protection XSS
• ☐ Pas d'utilisation de HTML Snippet avec contenu utilisateur
• ☐ Content Security Policy configurée
• ☐ Validation des entrées riches (rejection de <script>)

API et Authentification
• ☐ Tokens avec expiration (JWT ou custom)
• ☐ Rate limiting implémenté sur les endpoints critiques
• ☐ Validation Origin/Referer pour APIs
• ☐ SSO configuré (SAML/OIDC) si nécessaire

Infrastructure
• ☐ HTTPS forcé (redirection HTTP → HTTPS)
• ☐ X-Frame-Options: DENY
• ☐ HSTS (HTTP Strict Transport Security) activé
• ☐ Logs de sécurité activés et surveillés
Protection Brute Force
• ☐ Limitation de tentatives de login (5 max en 15 min)
• ☐ CAPTCHA sur page de login
• ☐ Blocage temporaire après échecs répétés

Conclusion

La sécurité est un processus continu. Mendix offre des protections robustes par défaut, mais leur
efficacité dépend d'une configuration correcte et de bonnes pratiques de développement. En
suivant ce guide, votre application ClubHub sera protégée contre les vulnérabilités les plus
courantes.

Points clés à retenir :

• Toujours activer le mode Production avec Entity Access Rules
• Utiliser XPath constraints pour empêcher IDOR
• Ne jamais faire confiance aux entrées utilisateur
• Implémenter SSO pour une authentification centralisée
• Surveiller et logger toutes les activités suspectes

Pour toute question ou assistance, consultez la documentation Mendix Security :

[Link]
Cartographier les flux (Data Flow Diagram)

Tu dois de1.3 Cartographier les flux (Data Flow Diagram)

Tu dois dessiner (mentalement ou sur papier) tous les flux.

Flux typiques

 User → Mendix (login)

 Mendix → IdP (authentification)
 IdP → Mendix (token)
 Mendix → Backend API
 Backend API → DB
 Backend API → IdP (validation token)

Chaque flèche = surface d’attaque.

Pose-toi pour CHAQUE flux :

 Est-il chiffré ?
 Est-il authentifié ?
 Est-il autorisé ?
 Est-il tracé ?

1.4 Définir les frontières de confiance (Trust Boundaries)

C’est LE concept central.

Exemples de frontières critiques

 🌍 Internet ↔ Mendix
 🧩 Mendix ↔ Backend API
 🔐 Backend ↔ IdP
 🗄 Backend ↔ DB

-Règle absolue

Tout ce qui traverse une frontière doit être revalidé

-Erreur fatale courante :

“Mendix a déjà vérifié le rôle, donc l’API peut faire confiance”

1.5 Hypothèses de confiance (Trust Assumptions)

 Liste explicitement ce que tu supposes vrai.

 Mauvaises hypothèses courantes:
 “Le token vient toujours de mon IdP”
 “Le front n’appellera jamais cet endpoint”
 “Les users ne peuvent pas modifier le JWT”
 “Personne ne connaît cette URL”

-En sécurité :

Toute hypothèse non vérifiée devient une vulnérabilité

1.6 Appliquer STRIDE (menace par catégorie)

Utilise STRIDE sur chaque composant :

Catégorie Exemple concret

S – Spoofing Usurper un utilisateur via token volé

T – Tampering Modifier payload API

R – Repudiation User nie une action (logs absents)

I – Information Disclosure API renvoie trop de données

D – Denial of Service Flood API / login

E – Elevation of Privilege User devient admin

➡️Tu ne cherches PAS à tout bloquer,

➡️Tu identifies où ça peut arriver.

1.7 Cas d’abus (Abuse Cases) – niveau avancé

Ce sont des scénarios réalistes, pas théoriques.

-Exemples:

Un user change le tenantId dans une requête

Un token user est utilisé sur une API admin

Un token expiré est encore accepté

Un service interne est appelé depuis Internet

-Pose la question :

“Comment j’abuserais du système si j’étais malveillant ?”

1.8 Livrable attendu (important)

À la fin du point 1, tu dois être capable de produire :

 ✅ Une liste d’actifs

 ✅ Une liste d’acteurs
 ✅ Un diagramme de flux
 ✅ Les trust boundaries
 ✅ Les hypothèses de confiance
 ✅ Les menaces principales par composant

Si tu n’as pas ça, le reste (auth, API, DB) sera fragile.

1.9 Erreurs fréquentes que je vois en audit

❌ Faire le threat modeling après le dev

❌ Se limiter à OWASP Web Top 10

❌ Ne pas documenter les hypothèses

❌ Confondre authentification et autorisationssiner (mentalement ou sur papier) tous les flux.

D’autres attaques possibles:
Broken Authentication (Faille d’authentification)
-Définition:

Failles dans la gestion des identités ou des sessions, qui permettent à un attaquant de :

 Se connecter avec un compte existant sans autorisation,

 Usurper une session d’utilisateur légitime.

-Risques principaux:

 Usurpation de compte admin ou utilisateur sensible

 Accès à des données confidentielles
 Modification de workflows ou de transactions

-Comment ça se traduit dans Mendix:

 Mendix fournit un système d’authentification robuste (par login/password, LDAP,

SSO, OAuth)
 Les sessions utilisateur sont gérées côté serveur

-Risque résiduel si :

 les mots de passe sont faibles ou réutilisés

 la politique de mot de passe n’est pas appliquée
 aucune MFA (authentification multi-facteurs) n’est utilisée
 les sessions ne sont pas invalidées correctement après logout

-Actions supplémentaires:

 Activer MFA pour les utilisateurs critiques

 Appliquer des politiques de mot de passe fortes
 Vérifier que les sessions sont invalidées après logout ou inactivité
 Limiter les tentatives de connexion (rate limiting)

Broken Access Control (Faille de contrôle d’accès)

-Définition:

Les utilisateurs accèdent à des fonctions ou données non autorisées, par manipulation directe ou
contournement du front-end.
-Risques principaux:

 Accès à des informations confidentielles

 Escalade de privilèges (user → admin)
 Modification de données sensibles

-Mendix:

Mendix fournit un système de rôles et permissions sur les entités et microflows

-Risque :

 Si les règles d’accès ne sont pas définies correctement pour chaque entité et microflow
 Si des widgets ou APIs exposent des données sans filtrage
 Si les ID d’objets (GUID) sont exposés dans le front-end sans contrôle

-Actions supplémentaires:

 Définir règles d’accès strictes par entité et microflow

 Ne pas exposer les GUID ou IDs sensibles directement au client
 Vérifier les roles et autorisations avant chaque action critique
 Implémenter un logging d’accès pour audit

Injection (SQL / XPath / OQL)

Définition

Un attaquant injecte du code malveillant dans une requête pour :

 lire, modifier ou supprimer des données

 exécuter des commandes non prévues

Risques principaux

 Vol ou corruption de données

 Exécution de scripts côté serveur
 Compromission de l’application ou du serveur

Mendix

Mendix utilise son ORM et microflows, ce qui limite fortement les risques d’injection

Risque résiduel :

 Si des requêtes SQL directes ou XPath dynamiques sont utilisées

 Si des entrées utilisateur ne sont pas correctement filtrées ou paramétrées
Actions supplémentaires

 Toujours utiliser les microflows et ORM standard pour accéder aux données
 Si SQL direct nécessaire → utiliser paramètres liés, pas de concaténation de chaînes
 Valider et filtrer toutes les entrées utilisateurs

File Upload Vulnerabilities (Vulnérabilités liées aux fichiers uploadés)

Définition

Les attaquants uploadent des fichiers malveillants pour :

 exécuter du code sur le serveur

 accéder à des fichiers sensibles
 provoquer des crashs ou un DoS

Risques principaux

 Exécution de code non autorisé

 Exfiltration de données
 Attaques par fichiers volumineux ou scripts intégrés

Mendix

Les objets FileDocument gèrent le stockage de fichiers

Risque résiduel

 Si aucun contrôle n’est appliqué sur type/taille/contenu

 Si les fichiers sont accessibles publiquement via URL directe
 Si les fichiers sont interprétés comme code (ex: HTML, JS, JSP, PHP dans certaines
configurations)

Actions supplémentaires

 Limiter les types de fichiers autorisés

 Limiter la taille maximale
 Stocker les fichiers hors dossier exécutable du serveur
 Scanner les fichiers uploadés avec un antivirus si nécessaire
 Restreindre l’accès via rôles et permissions Mendix