Aller au contenu

Tests des interfaces et sécurité

"Chaque interface est un contrat… et une surface d’attaque."

Principe de conception sécurisée

Objectifs pédagogiques

À la fin de cette page, vous serez capable de :

  • identifier les différentes interfaces d’un système
  • tester une interface backend (API)
  • comprendre les principaux risques de sécurité
  • appliquer des contrôles de base lors des tests

Qu’est-ce qu’une interface ?

Une interface est un point de communication entre : - un utilisateur et l’application - deux systèmes - un client et un serveur

Exemples d’interfaces

  • API REST
  • formulaires web
  • endpoints HTTP
  • interfaces d’administration

👉 En backend, l’interface principale est souvent l’API.

Tests des interfaces backend

Les tests des interfaces backend consistent à vérifier :

  • les routes accessibles
  • les méthodes HTTP autorisées
  • les paramètres attendus
  • les réponses retournées
  • les codes de statut HTTP
  • les messages d’erreur

Ces tests peuvent être : - manuels - automatisés (tests API)

Exemple fil rouge – Interfaces de l’application MyEvents

Dans l’application MyEvents, l’interface principale est une API REST
utilisée par : - une application web - une application mobile - des services externes (paiement, notifications)

Chaque endpoint de l’API constitue une interface exposée qui doit être testée.

Exemples d’interfaces critiques MyEvents

Interface (endpoint) Rôle
POST /auth/login Authentification utilisateur
POST /events Création d’un événement
GET /events/{id} Consultation d’un événement
POST /tickets/purchase Achat de billet
GET /users/me Accès à l’espace utilisateur

👉 Ces interfaces sont des points d’entrée sensibles du système.

🧪 Exemples de tests d’interface (API) – MyEvents

✔️ Test fonctionnel d’interface

  • Given un utilisateur authentifié
  • When il appelle POST /events avec des données valides
  • Then la réponse est 201 Created
  • And l’événement est enregistré en base

❌ Test d’erreur (sécurité / validation)

  • Given un utilisateur non authentifié
  • When il appelle POST /events
  • Then la réponse est 401 Unauthorized
  • And aucune donnée n’est créée

🔐 Test d’autorisation

  • Given un utilisateur standard
  • When il tente d’accéder à GET /admin/users
  • Then la réponse est 403 Forbidden

🔒 Tests de sécurité spécifiques à MyEvents

Pour MyEvents, les tests de sécurité sur les interfaces doivent vérifier :

  • impossibilité d’acheter un billet sans authentification
  • impossibilité d’accéder aux données d’un autre utilisateur
  • validation stricte des paramètres (ID, prix, quantités)
  • absence d’informations sensibles dans les messages d’erreur
  • protection contre les tentatives répétées (brute force)

👉 Une API fonctionnelle mais non sécurisée est inacceptable.

Lien avec les autres chapitres

Ces tests d’interface reposent sur :

Ils constituent la dernière ligne de défense avant la production.

Pourquoi tester la sécurité ?

Une application fonctionnelle peut être totalement vulnérable.

Les tests de sécurité permettent de : - protéger les données - éviter les accès non autorisés - réduire les risques d’attaque - respecter les exigences légales

👉 La sécurité fait partie de la qualité.

Principaux risques liés aux interfaces

1️⃣ Authentification

  • accès sans identification
  • gestion incorrecte des sessions
  • mots de passe faibles

2️⃣ Autorisation

  • accès à des ressources interdites
  • élévation de privilèges

3️⃣ Validation des entrées

  • données non contrôlées
  • injections (SQL, commandes, scripts)

4️⃣ Gestion des erreurs

  • messages trop détaillés
  • divulgation d’informations sensibles

Tests de sécurité courants (niveau module 450)

Sans être expert sécurité, un testeur doit vérifier :

  • accès protégé aux routes sensibles
  • refus des requêtes non authentifiées
  • validation stricte des entrées
  • gestion correcte des erreurs
  • journalisation des actions critiques

👉 Ces contrôles sont essentiels en backend.

Lien avec le reste du module

Les tests des interfaces et de sécurité s’appuient sur : - les cas de test (chapitre 6) - les tests automatisés (chapitre 7) - les mesures correctives (chapitre 8)

Ils constituent la dernière barrière avant la mise en production.

À retenir

  • une interface est toujours exposée
  • la sécurité doit être testée, pas supposée
  • le testeur n’est pas un hacker, mais un réducteur de risques
  • tester la sécurité fait partie du rôle professionnel

⬅ Introduction au TDD ➡ Travaux pratiques