Hash, trigger MySQL, gestion des droits, requêtes SQL de surveillance, API REST, validation des paramètres et tests unitaires.
Le sujet Casterman est un cas très représentatif de l’épreuve BTS SIO SLAM : il mélange sécurité applicative, base de données, code Java, SQL et API REST. Pour réussir, il ne faut pas seulement réciter des notions : il faut expliquer les risques, corriger les erreurs et justifier les choix techniques. Cette page reprend les quatre axes utiles pour réussir : analyse du cas, méthodologies, exemples modèles et pièges à éviter.
Casterman est une librairie spécialisée dans la bande dessinée. Le sujet demande de sécuriser plusieurs éléments du système d’information : l’authentification des utilisateurs, l’historique des mots de passe, la gestion des droits, la détection d’activités anormales et l’accès à une API REST.
OLD et NEW.NullPointerException.GROUP BY et HAVING.Le sujet Casterman évalue surtout votre capacité à distinguer une solution qui “fonctionne” d’une solution vraiment robuste. Un trigger peut être syntaxiquement correct mais métierement faux. Une méthode Java peut marcher dans un cas normal mais planter avec une liste vide. Une requête SQL peut sélectionner les bonnes lignes mais oublier le regroupement nécessaire. C’est exactement ce que le correcteur cherche à repérer.
Une bonne copie explique les mécanismes. Par exemple : “Dans un trigger BEFORE UPDATE, OLD.mdpActuel désigne l’ancien mot de passe à archiver, tandis que NEW.mdpActuel désigne le nouveau mot de passe. Utiliser NEW dans la vérification d’historique empêche d’enregistrer correctement l’ancien mot de passe.”
| Bloc | Compétence attendue | Erreur à éviter |
|---|---|---|
| Hash / mot de passe | Justifier le hachage irréversible | Proposer un chiffrement réversible pour stocker un mot de passe |
| Trigger MySQL | Utiliser correctement OLD et NEW | Historiser le nouveau mot de passe au lieu de l’ancien |
| Droits Java | Parcourir une collection de droits de manière robuste | Oublier de tester null ou liste vide |
| SQL surveillance | Utiliser GROUP BY puis HAVING | Écrire WHERE COUNT(*) > 5 |
| API REST | Valider les paramètres et sécuriser l’accès aux données | Faire confiance à un paramètre reçu dans l’URL |
La formulation à retenir : on chiffre une donnée que l’on doit relire, mais on hache un mot de passe que l’on doit seulement vérifier.
BEFORE UPDATE, AFTER INSERT, etc.OLD pour les valeurs avant modification.NEW pour les valeurs après modification.Avant de parcourir une collection, il faut vérifier qu’elle existe et qu’elle n’est pas vide. Ensuite, la méthode peut parcourir les droits et comparer la table et l’opération demandées.
public boolean possedeDroit(String uneTable, String uneOperation) {
if (this.lesDroits == null || this.lesDroits.isEmpty()) {
return false;
}
for (Droit d : this.lesDroits) {
if (d.getTable().equals(uneTable) &&
d.getOperation().equals(uneOperation)) {
return true;
}
}
return false;
}
Il faut filtrer les lignes avec WHERE, regrouper avec GROUP BY, puis filtrer les groupes avec HAVING.
SELECT idUtilisateur, COUNT(*) AS nbAjouts
FROM Log
WHERE nomTable = 'BandeDessinee'
AND operation = 'insert'
AND dateHeure >= CONCAT(CURRENT_DATE(), ' 08:00:00')
GROUP BY idUtilisateur
HAVING COUNT(*) > 5
ORDER BY nbAjouts DESC;
Casterman n’est pas difficile parce qu’il serait imprévisible. Il est difficile parce qu’il exige de la précision : un mauvais mot-clé, une confusion OLD/NEW ou un HAVING oublié peuvent coûter beaucoup de points. En revanche, les réponses deviennent très solides si vous structurez toujours votre raisonnement.
“Le mot de passe ne doit pas être chiffré car le chiffrement est réversible : si la clé est compromise, tous les mots de passe peuvent être retrouvés en clair. Il faut utiliser un hachage robuste comme bcrypt. Lors de la connexion, on hache le mot de passe saisi et on compare le résultat avec le hash stocké.”
“Dans le trigger BEFORE UPDATE, l’ancien mot de passe doit être récupéré avec OLD.mdpActuel. La valeur NEW.mdpActuel correspond au nouveau mot de passe et ne doit pas être utilisée pour historiser l’ancien. La correction permet de conserver l’historique des mots de passe déjà utilisés.”
“La méthode doit d’abord vérifier si la liste des droits est nulle ou vide. Si c’est le cas, elle retourne false. Ensuite seulement, elle parcourt les droits et vérifie simultanément la table et l’opération demandées.”
“La requête doit regrouper les logs par utilisateur afin de compter les ajouts. La clause HAVING COUNT(*) > 5 filtre les utilisateurs ayant ajouté plus de cinq bandes dessinées depuis huit heures, ce qui permet de détecter une activité anormale.”
“Un paramètre reçu par une API REST doit être validé avant utilisation. Pour un ISBN, on peut imposer un format numérique attendu, puis utiliser une requête préparée. Cette double protection limite les erreurs et empêche l’injection SQL.”
Pour un mot de passe, le chiffrement est une mauvaise réponse car il est réversible. Le correcteur attend le hachage irréversible, idéalement avec bcrypt ou Argon2.
Dans un trigger de mise à jour, NEW contient la nouvelle valeur et OLD l’ancienne. Pour historiser l’ancien mot de passe, il faut donc utiliser OLD.mdpActuel.
Une collection nulle provoque une NullPointerException. Le test de nullité et de liste vide est indispensable dans une méthode robuste.
COUNT(*) est un agrégat calculé après regroupement. Il faut donc utiliser HAVING COUNT(*) > 5, pas WHERE COUNT(*) > 5.
Une validation JavaScript côté navigateur peut être contournée. Les contrôles doivent être faits côté serveur avant toute requête SQL ou tout accès aux données.
OLD, NEW, HAVING, requête préparée.Une très bonne copie ne se contente pas de corriger. Elle démontre la compréhension : pourquoi le hachage est adapté, pourquoi OLD est nécessaire, pourquoi HAVING est obligatoire et pourquoi une API doit valider ses paramètres côté serveur.
Le sujet porte sur la sécurité applicative : hachage des mots de passe, trigger MySQL, gestion des droits, requêtes SQL de surveillance et API REST.
Parce que le hachage est irréversible. Même si la base est volée, les mots de passe en clair ne peuvent pas être retrouvés directement.
L’erreur consiste à utiliser NEW.mdpActuel alors qu’il faut utiliser OLD.mdpActuel pour historiser l’ancien mot de passe.
HAVING filtre les résultats après le regroupement, ce qui permet de sélectionner les utilisateurs dont le nombre d’ajouts dépasse un seuil.
Il faut valider les paramètres reçus, refuser les formats incorrects, utiliser des requêtes préparées et ne jamais faire confiance directement aux données reçues dans l’URL.
Sujet complet BTS SIO 2025 SLAM Casterman pour travailler l’épreuve.
📄 Sujet complet PDFRetrouvez les autres sujets BTS SIO disponibles pour compléter vos révisions.