Bases des Tests de Sécurité que Tout Ingénieur QA Devrait Connaître

Les ingénieurs QA peuvent détecter une catégorie significative de bugs de sécurité pendant les tests fonctionnels habituels, sans outils spécialisés ni certifications.

Ce que les ingénieurs QA peuvent tester sans outils spécialisés

Authentification et gestion des sessions

Les bugs de sécurité les plus courants se trouvent dans les flux d'authentification. Testez ces points pendant vos tests fonctionnels habituels :

Protection contre le brute force : soumettez un mauvais mot de passe dix fois de suite. L'application bloque-t-elle le compte ou applique-t-elle un rate limiting ? Si non, c'est une découverte à signaler. Fixation de session : connectez-vous. Copiez le cookie de session. Déconnectez-vous. Essayez d'utiliser l'ancien cookie. S'il fonctionne encore, les sessions ne sont pas invalidées à la déconnexion. Durée du "rester connecté" : activez "rester connecté", fermez le navigateur, rouvrez-le après 30 jours (ou avancez l'horloge système). La session fonctionne-t-elle encore ? Pendant combien de temps ? Réutilisation du lien de réinitialisation de mot de passe : demandez un e-mail de réinitialisation. Utilisez le lien pour réinitialiser. Essayez le lien une deuxième fois. Il devrait être invalide. S'il fonctionne deux fois, c'est un bug. Sessions simultanées : connectez-vous sur deux navigateurs différents en même temps. L'une ou l'autre session devrait-elle être invalidée ?

Autorisation (contrôle d'accès)

C'est là que se cachent la plupart des bugs graves :

Escalade de privilèges horizontale : créez deux comptes (utilisateur A et utilisateur B). En tant qu'utilisateur A, créez une ressource (une commande, un document, un élément de profil). Notez l'ID de la ressource dans l'URL. Connectez-vous en tant qu'utilisateur B. Essayez d'accéder, de modifier ou de supprimer la ressource de l'utilisateur A par son ID. Si vous pouvez, c'est un bug BOLA (Broken Object Level Authorization), l'une des vulnérabilités API les plus courantes.

GET /api/orders/12345   ← commande de l'utilisateur A

Connectez-vous en tant qu'utilisateur B et appelez la même URL. Que se passe-t-il ?

Escalade de privilèges verticale : essayez d'accéder aux fonctionnalités d'administration en tant qu'utilisateur standard. Vérifiez les URLs admin (/admin, /dashboard/admin, /api/admin/*) sans identifiants administrateur. IDOR dans les réponses API : l'API renvoie-t-elle uniquement les données que l'utilisateur actuel devrait voir ? Vérifiez si l'appel API d'un utilisateur standard retourne parfois des données d'autres utilisateurs dans l'un des champs.

Validation des entrées

Chaque champ de formulaire est un point d'injection potentiel :

Injection SQL (test de base) : saisissez ' (guillemet simple) dans n'importe quel champ texte. L'application retourne-t-elle une erreur de base de données ? Si oui, elle est probablement vulnérable. XSS (test de base) : saisissez dans n'importe quel champ dont le contenu est affiché aux utilisateurs (champs nom, commentaires, adresses). Si une boîte d'alerte apparaît, c'est du XSS stocké. Path traversal : essayez ../../../etc/passwd dans les champs de nom de fichier ou les paramètres d'URL. L'application devrait retourner une erreur, pas le contenu du fichier.

Ces tests manuels sont rapides et détectent les vulnérabilités les plus évidentes. Ils ne remplacent pas un scan de sécurité automatisé, mais valent la peine d'être réalisés sur chaque nouvelle fonctionnalité.

HTTPS et cookies

Vérifiez dans les DevTools du navigateur :

Le site est-il servi en HTTPS ? HTTP redirige-t-il vers HTTPS ?
Les cookies de session sont-ils marqués HttpOnly (inaccessibles depuis JavaScript) ?
Les cookies de session sont-ils marqués Secure (envoyés uniquement via HTTPS) ?
SameSite est-il défini sur Strict ou Lax pour les cookies d'authentification ?

Avec Playwright :

test('auth cookie has security flags', async ({ page, context }) => {
  await page.goto('/login');
  // ... effectuer la connexion

  const cookies = await context.cookies();
  const sessionCookie = cookies.find(c => c.name === 'session_token');

  expect(sessionCookie?.httpOnly).toBe(true);
  expect(sessionCookie?.secure).toBe(true);
  expect(sessionCookie?.sameSite).toMatch(/strict|lax/i);
});

Messages d'erreur et divulgation d'informations

Des messages d'erreur trop explicites constituent un problème de sécurité :

"Utilisateur introuvable" vs "Identifiants invalides" : le premier indique aux attaquants quels comptes existent
Des stack traces dans les réponses de production
Des chemins internes du serveur, des noms de bases de données ou des versions de bibliothèques dans les messages d'erreur
Des réponses API qui incluent des champs comme passwordHash, internalId ou des indicateurs d'administration

Intégrer la sécurité dans votre processus de test

Scan de base OWASP ZAP

OWASP ZAP est gratuit et peut s'exécuter en mode scanner passif en parallèle de vos tests Playwright. Le scan de base explore votre application et signale les problèmes évidents :

# .github/workflows/security.yml
- name: ZAP Baseline Scan
  uses: zaproxy/action-baseline@v0.10.0
  with:
    target: 'https://staging.myapp.com'
    rules_file_name: '.zap/rules.tsv'

Ce scan détecte les en-têtes de sécurité manquants, les cookies non sécurisés et les informations serveur exposées, sans que vous ayez à écrire du code de test.

Vérification des en-têtes de sécurité

En-têtes que votre application devrait envoyer :

Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin

Testez-les avec Playwright :

test('security headers are present', async ({ request }) => {
  const response = await request.get('https://myapp.com');
  const headers = response.headers();

  expect(headers['x-content-type-options']).toBe('nosniff');
  expect(headers['x-frame-options']).toBe('DENY');
  expect(headers['strict-transport-security']).toContain('max-age=');
});

Ce que les ingénieurs QA doivent confier aux spécialistes en sécurité

Certains tests de sécurité nécessitent des compétences et des outils spécialisés :

Tests de pénétration complets
Analyse binaire
Revue de cryptographie
Sécurité de l'infrastructure (configuration cloud, segmentation réseau)
Tests d'ingénierie sociale

Quand vous trouvez un problème de sécurité potentiel lors de tests manuels, documentez-le clairement (étapes de reproduction, impact potentiel). Escaladez vers votre équipe sécurité ou signalez-le comme bug de haute sévérité. N'essayez pas de prouver l'exploitabilité vous-même : votre rôle est de trouver, pas d'exploiter.

La meilleure posture de sécurité repose sur la défense en profondeur. Le QA détecte les problèmes évidents pendant le développement, les scanners automatisés détectent les problèmes systématiques en CI. Les spécialistes réalisent la revue approfondie avant les releases majeures.