Trigger MySQL, API REST, clé API, jeton temporaire, HTTPS, IDOR, injection SQL et surveillance des accès.
Le sujet Kirassur est un cas typique de BTS SIO SLAM : il ne suffit pas de connaître les mots-clés techniques, il faut comprendre les risques applicatifs et justifier les corrections proposées. La page reprend les quatre axes utiles pour réussir : analyse du cas, méthodologies, exemples modèles et pièges à éviter.
Kirassur est une compagnie d’assurance automobile qui doit sécuriser son système applicatif. Le sujet met en avant trois enjeux : la fiabilité des règles métier dans la base de données, la sécurisation d’une API accessible par des partenaires et la surveillance des actions sensibles par journalisation.
Le sujet ne demande pas seulement de “corriger du code”. Il demande de montrer que vous comprenez pourquoi le code est dangereux. Chaque faille doit être reliée à un risque concret : accès aux contrats d’autres assurés, divulgation de données personnelles, contournement des règles métier ou exploitation d’une requête SQL mal construite.
Une bonne copie ne se contente pas de nommer “IDOR”, “HTTPS” ou “injection SQL”. Elle explique le mécanisme, donne la conséquence et propose une correction. La phrase gagnante ressemble à ceci : “Le paramètre idContrat ne peut pas être utilisé seul ; le serveur doit vérifier que le contrat demandé appartient bien au partenaire authentifié par la clé API ou à l’assuré associé au jeton.”
| Bloc | Compétence attendue | Erreur à éviter |
|---|---|---|
| Trigger MySQL | Faire respecter une règle métier en base | Compter tous les sinistres au lieu de filtrer la garantie concernée |
| API REST | Sécuriser les accès aux contrats | Confondre authentification et autorisation |
| Logs | Surveiller les actions anormales | Logger sans exploiter les traces pour détecter les attaques |
WHERE pour filtrer sur le contrat et sur la garantie.Le point clé : un trigger n’est pas seulement du SQL. C’est une règle métier automatisée. Si la règle est mal traduite, le code peut être syntaxiquement correct mais fonctionnellement faux.
idContrat, token, cleAPI.Le réflexe attendu est toujours le même : remplacer la concaténation de chaînes par une requête préparée. Une donnée utilisateur ne doit jamais être insérée directement dans une requête SQL.
$stmt = $pdo->prepare(
"SELECT * FROM Token WHERE valeur = :token"
);
$stmt->bindParam(':token', $_GET['token']);
$stmt->execute();Cette structure empêche que la valeur transmise dans l’URL soit interprétée comme une instruction SQL.
Kirassur est exigeant car il combine développement, base de données et cybersécurité. Toutefois, les questions deviennent très accessibles si vous utilisez toujours la même logique : identifier le risque, expliquer l’exploitation possible, proposer une correction et justifier l’amélioration obtenue.
“Le trigger doit compter uniquement les sinistres de la garantie concernée par la nouvelle déclaration. Si la requête compte tous les sinistres du contrat, elle peut signaler à tort un bris de glace alors que les sinistres précédents concernent une autre garantie. Il faut donc compléter la condition avec le contrat et la garantie : Sinistre.idContrat = NEW.idContrat et Sinistre.idGarantie = NEW.idGarantie.”
“La clé API identifie le partenaire et donne accès au service applicatif. Elle ne doit pas être transmise à l’assuré car elle ouvrirait un accès trop large. L’assuré doit recevoir un jeton temporaire, limité à son contrat et valable seulement quelques minutes. Cette solution applique le principe de moindre privilège.”
“HTTPS chiffre les échanges entre le client et le serveur. Il empêche un attaquant réseau de lire ou modifier les données en transit. En revanche, il ne corrige pas les failles de l’application : si le code accepte un idContrat non autorisé ou concatène un paramètre dans une requête SQL, la faille reste exploitable même en HTTPS.”
“Avant de renvoyer les données d’un contrat, l’API doit vérifier que ce contrat appartient bien au partenaire identifié par la clé API ou à l’assuré associé au jeton. Si cette vérification échoue, le serveur doit renvoyer une erreur 403 sans divulguer les données du contrat.”
“La requête ne doit pas concaténer directement la valeur du paramètre token. Une requête préparée avec paramètre lié permet de traiter le jeton comme une donnée et non comme du code SQL. Cela neutralise les tentatives d’injection.”
Une clé API valide prouve que l’appel vient d’un partenaire connu. Cela ne prouve pas que ce partenaire a le droit de consulter tous les contrats. Il faut ensuite vérifier l’appartenance du contrat demandé.
HTTPS protège le transport. Il ne protège pas contre une faille IDOR, une injection SQL, une mauvaise gestion des rôles ou une absence de contrôle côté serveur.
Limiter la taille d’un champ peut réduire certains abus, mais ce n’est pas une protection fiable contre SQL injection. La réponse attendue est la requête préparée avec paramètres liés.
Le trigger doit correspondre à la règle exacte. Si la règle concerne une garantie précise, le compteur doit filtrer cette garantie. Sinon, la base applique une règle erronée.
Logger une action ne suffit pas. Il faut indiquer ce que les logs permettent de détecter : énumération d’identifiants, accès refusés répétés, utilisation de jetons expirés ou appels anormaux à l’API.
Une très bonne copie utilise un vocabulaire précis : moindre privilège, contrôle d’autorisation côté serveur, requête préparée, IDOR, jeton temporaire, traçabilité. Elle ne se contente pas de dire “sécuriser” : elle explique la faille, l’impact et la correction.
Le sujet porte sur la sécurité applicative : trigger MySQL, API REST, gestion de jetons, HTTPS, IDOR, injection SQL et journalisation.
Le jeton limite l’accès à un contrat et à une durée courte. La clé API du partenaire donne un accès beaucoup plus large et ne doit pas être exposée à l’assuré.
L’erreur consiste à récupérer un contrat par son identifiant sans vérifier que l’utilisateur ou le partenaire a bien le droit d’y accéder.
Non. HTTPS protège les échanges réseau, mais l’injection SQL doit être corrigée dans le code avec des requêtes préparées.
Il faut expliquer ce que les logs permettent de détecter : accès refusés, énumération de contrats, jetons expirés ou comportements suspects.
Sujet complet BTS SIO 2025 SLAM Kirassur pour travailler l’épreuve.
📄 Sujet complet PDFRetrouvez les autres sujets BTS SIO disponibles pour compléter vos révisions.