Hoja de repaso: Introduction à l'Architecture MVC et Sécurité API

📋 Plan du Cours

1. Architecture MVC
2. Rôles composants MVC
3. Exemples MVC
4. Avantages MVC
5. API REST principes
6. Méthodes HTTP REST
7. Sécurité API REST
8. Authentification & sécurité
9. Vulnérabilités OWASP 2025
10. Contrôle d’accès défaillant
11. Injection SQL & XSS
12. Cryptographie faible

📖 1. Architecture MVC

🔑 Notions clés & Définitions

• Modèle (Model) : gestion des données et de la logique métier de l’application, séparé de l’affichage et de la gestion des interactions utilisateur.
• Vue (View) : composant responsable de l’affichage des données à l’utilisateur, sans logique métier.
• Contrôleur (Controller) : réceptionne les entrées utilisateur, orchestre les actions à partir de celles-ci, et décide quelle vue doit être affichée.
• But du MVC : organiser le code pour faciliter sa maintenance, sa réutilisabilité et sa clarté, en séparant clairement les responsabilités.
• Référence : B2 - Architecture MVC (table des matières, 1.1) : l’architecture MVC permet une séparation en Modèle, Vue, Contrôleur pour structurer le code d’une application.

📝 Points essentiels

• Le Modèle est dédié à la gestion des données et de la logique métier, sans se soucier de leur présentation ou de l’interaction utilisateur.
• La Vue affiche les données fournies par le Modèle, en étant indépendante de la logique métier, ce qui facilite la réutilisation et la maintenance.
• Le Contrôleur agit comme un orchestrateur : il reçoit les entrées utilisateur, traite la logique nécessaire (via le Modèle), et détermine la Vue à afficher.
• Le but principal du MVC est d’organiser le code pour qu’il soit plus lisible, modulaire et facilement maintenable, en séparant les responsabilités.
• La séparation en MVC est une pratique recommandée pour structurer des applications complexes, notamment dans le développement web, afin de faciliter la gestion et l’évolution du code.
• La référence B2 précise que cette architecture est une façon d’organiser le code en séparant gestion des données, affichage, et orchestration, pour une meilleure organisation.

💡 À retenir

L’architecture MVC divise une application en trois composants principaux — Modèle, Vue, Contrôleur — pour optimiser la maintenance, la réutilisabilité et la clarté du code.

📖 2. Rôles composants MVC

🔑 Notions clés & Définitions

• Rôle du Modèle (Model) : représente les données de l’application et la logique métier associée. Il interagit avec la base de données pour récupérer, enregistrer ou mettre à jour des données. (source : contenu source)

• Rôle du Contrôleur (Controller) : reçoit les requêtes HTTP, orchestre le flux de l’application en validant les données, en appelant le modèle pour manipuler les données, puis en choisissant la vue pour l’affichage. (source : contenu source)

• Rôle de la Vue (View) : responsable de l’affichage des données à l’utilisateur via une interface graphique ou textuelle. Elle ne doit pas contenir de logique métier, mais uniquement présenter les données fournies par le contrôleur. (source : contenu source)

• Interaction avec la base de données : le modèle gère cette interaction, en utilisant des requêtes pour récupérer ou modifier les données stockées. (source : contenu source)

• Validation et orchestration : le contrôleur valide les données entrantes, appelle le modèle pour traitement, puis détermine la vue à afficher. (source : contenu source)

• Absence de logique métier dans la Vue : la vue ne doit pas traiter de logique métier, mais uniquement afficher les données préparées par le contrôleur. (source : contenu source)

📝 Points essentiels

• Le Modèle est le seul responsable de l’interaction avec la base de données, assurant la récupération et la mise à jour des données, ainsi que la gestion de la logique métier. (source : contenu source)

• Le Contrôleur agit comme un orchestrateur : il réceptionne les requêtes HTTP, valide les données, appelle le modèle pour manipuler ces données, puis choisit la vue appropriée pour l’affichage. (source : contenu source)

• La Vue se limite à l’affichage des données, en fournissant une interface utilisateur. Elle ne doit pas contenir de logique métier, mais simplement présenter les données préparées par le contrôleur. (source : contenu source)

• La séparation claire de ces rôles facilite la maintenance, la réutilisabilité et la testabilité de l’application. (source : contenu source)

• La interaction avec la base de données est exclusivement assurée par le modèle, garantissant une architecture modulaire et cohérente. (source : contenu source)

💡 À retenir

Le modèle gère les données et la logique métier, le contrôleur orchestre le traitement des requêtes, et la vue affiche les données sans logique métier, assurant une séparation claire des responsabilités dans l’architecture MVC.

📖 3. Exemples MVC

🔑 Notions clés & Définitions

• Exemple 1 : MVC procédural simple avec tableau PHP et formulaire HTML : Implémentation du modèle MVC sans programmation orientée objet, utilisant un tableau PHP pour stocker les données, un script unique pour la logique (contrôleur) et du HTML pour l’affichage (vue).
• Exemple 2 : MVC procédural avec PDO et séparation fichiers model, controller, view : Architecture MVC où chaque composant est dans un fichier distinct, utilisant PDO pour l’accès à la base de données, facilitant la maintenance et la sécurité.
• Exemple 3 : MVC orienté objet avec classes Etudiant et EtudiantController et inclusion de vue : Approche MVC utilisant la programmation orientée objet, avec des classes pour le modèle (Etudiant) et le contrôleur (EtudiantController), séparant clairement la logique métier, la gestion des données et l’affichage.

📝 Points essentiels

• Exemple 1 : La simplicité du MVC procédural avec tableau PHP permet une compréhension rapide mais limite la modularité et la maintenabilité. La logique est intégrée dans un seul script, ce qui peut compliquer l’évolution du code.
• Exemple 2 : La séparation en fichiers distincts (model, controller, view) avec PDO favorise la sécurité (préparations de requêtes) et la clarté du code, facilitant la maintenance et la réutilisation.
• Exemple 3 : La version orientée objet structure le code en classes, permettant une meilleure organisation, réutilisation et extensibilité. La communication entre composants se fait via des méthodes, et la vue est incluse dans le contrôleur ou séparée.
• Rôle des composants :
  • Modèle : gestion des données, interaction avec la base (ex : récupération, insertion).
  • Contrôleur : réception des requêtes, orchestration, appel au modèle, transmission à la vue.
  • Vue : affichage des données, interface utilisateur, sans logique métier.
• Exemples concrets :
  • Exemple 1 montre un MVC procédural simple avec un tableau PHP et un formulaire HTML pour ajouter des étudiants.
  • Exemple 2 illustre une architecture modulaire avec PDO, séparant la gestion des données dans un fichier modèle, le contrôleur dans un script dédié, et des vues pour l’affichage.
  • Exemple 3 présente une approche orientée objet avec des classes pour le modèle et le contrôleur, et une inclusion de vue pour l’affichage.

💡 À retenir

Les exemples illustrent la progression du MVC procédural simple à une architecture orientée objet, chaque étape améliorant la modularité, la sécurité et la maintenabilité du code.

📖 4. Avantages MVC

🔑 Notions clés & Définitions

Séparation des responsabilités : La division claire entre différentes composantes (Modèle, Vue, Contrôleur) permet de décharger chaque partie de responsabilités spécifiques, facilitant la maintenance et l’évolution du code.
(voir section 1)

Réutilisabilité des composants : La modularité du MVC permet de réutiliser facilement des composants ou des parties de l’application dans d’autres contextes ou projets, grâce à leur indépendance et leur encapsulation.
(voir section 1)

Testabilité indépendante des composants : La conception modulaire du MVC facilite la mise en place de tests unitaires ou d’intégration pour chaque composant séparément, sans dépendre des autres parties du système.
(voir section 1)

📝 Points essentiels

• La séparation des responsabilités est le principe fondamental du MVC, qui permet de structurer le code pour une meilleure organisation, notamment en isolant la logique métier (Modèle), l’affichage (Vue), et la gestion des interactions (Contrôleur).
• La réutilisabilité des composants est renforcée par la modularité du MVC, permettant de réutiliser une Vue ou un Modèle dans différentes parties de l’application ou dans d’autres projets, ce qui réduit la duplication de code.
• La testabilité indépendante est un avantage clé, car chaque composant peut être testé isolément, ce qui facilite la détection et la correction des bugs, et garantit la stabilité lors des évolutions.
• Ces avantages contribuent à une meilleure maintenance, une évolutivité accrue, et une qualité logicielle améliorée.

💡 À retenir

Les avantages du MVC résident principalement dans sa capacité à organiser le code en séparant clairement les responsabilités, ce qui facilite la réutilisation des composants et leur testabilité indépendante, améliorant ainsi la qualité et la pérennité des applications.

📖 5. API REST principes

🔑 Notions clés & Définitions

Principes de l’API REST (voir source) : ensemble de règles pour concevoir des services web légers, où chaque ressource est identifiée par une URL et manipulée via des méthodes HTTP standard.

Ressource (voir source) : élément ou donnée spécifique accessible via une API REST, identifiée par une URL unique.

Statelessness (voir source) : principe selon lequel chaque requête doit contenir toutes les informations nécessaires pour être traitée, sans dépendance à un état côté serveur, facilitant la scalabilité.

Représentation (voir source) : format de données utilisé pour transmettre une ressource, généralement JSON ou XML, permettant au client de comprendre et manipuler l’état de la ressource.

📝 Points essentiels

Les principes fondamentaux de REST, tels que Statelessness (sans état), garantissent que chaque requête est autonome, ce qui simplifie la mise à l’échelle et la gestion des serveurs. La ressource est identifiée par une URL claire, souvent au pluriel, et manipulée à l’aide des méthodes HTTP standard : GET pour récupérer, POST pour créer, PUT pour remplacer, PATCH pour modifier partiellement, et DELETE pour supprimer. La réponse est généralement au format JSON, favorisé pour sa légèreté et sa simplicité d’utilisation, mais XML reste aussi utilisé dans certains contextes. La conception d’une API REST doit respecter une hiérarchie logique dans les URL, inclure un versioning, et fournir des messages d’erreur clairs. La statelessness permet à chaque requête d’être indépendante, ce qui facilite la scalabilité et la résilience du système. Enfin, l’utilisation de formats standardisés comme JSON ou XML assure une communication efficace et compréhensible entre client et serveur.

💡 À retenir

Les API REST, en respectant les principes de ressources identifiées par URL, méthodes HTTP standard, statelessness et formats JSON ou XML, offrent une architecture simple, évolutive et interopérable pour le développement de services web modernes.

📖 6. Méthodes HTTP REST

🔑 Notions clés & Définitions

• GET : méthode utilisée pour récupérer une ressource ou une collection de ressources. Elle ne modifie pas l’état du serveur et doit être idempotente.
  (voir API REST, 2023)

• POST : méthode permettant de créer une nouvelle ressource sur le serveur. Elle envoie des données dans le corps de la requête, souvent au format JSON ou XML.
  (voir API REST, 2023)

• PUT : méthode utilisée pour effectuer une mise à jour complète d’une ressource existante. Elle remplace entièrement la ressource ciblée par la contenu fourni.
  (voir API REST, 2023)

• DELETE : méthode permettant de supprimer une ressource spécifique. Elle doit être idempotente, c’est-à-dire que plusieurs requêtes identiques ont le même effet que une seule.
  (voir API REST, 2023)

• Respect des principes REST : utilisation correcte des méthodes HTTP en fonction de leur rôle (GET pour lire, POST pour créer, PUT pour mettre à jour, DELETE pour supprimer), afin d’assurer une cohérence et une conformité à l’architecture REST.
  (voir API REST, 2023)

📝 Points essentiels

• La méthode GET doit uniquement servir à récupérer des données sans modifier l’état du serveur. Elle doit être sûre et idempotente, ce qui signifie qu’elle peut être répétée sans effets secondaires.
• La méthode POST est utilisée pour créer une nouvelle ressource, en envoyant des données dans le corps de la requête. Elle peut générer une nouvelle URL ou identifiant pour la ressource créée.
• La méthode PUT doit effectuer une mise à jour complète d’une ressource existante, en remplaçant son contenu par celui fourni. Elle doit être idempotente, c’est-à-dire que plusieurs requêtes identiques produisent le même résultat.
• La méthode DELETE supprime une ressource spécifique. Elle doit également être idempotente, garantissant que plusieurs suppressions successives n’ont pas d’effet supplémentaire.
• L’utilisation correcte de ces méthodes permet de respecter les principes de REST, notamment la cohérence, la prévisibilité et la simplicité dans la conception des API.
• La conformité à ces usages facilite l’interopérabilité, la maintenance et la scalabilité des systèmes RESTful.

💡 À retenir

Les méthodes HTTP REST (GET, POST, PUT, DELETE) doivent être utilisées selon leur rôle précis pour garantir la conformité à l’architecture REST, assurer la sécurité et la cohérence des échanges, et respecter le principe d’idempotence quand cela est requis.

📖 7. Sécurité API REST

🔑 Notions clés & Définitions

• Validation des entrées : Processus de vérification et de contrôle des données reçues par l’API afin d’assurer leur conformité aux formats attendus et éviter l’injection ou autres attaques. (voir section 11)

• Utilisation de HTTPS : Mise en œuvre du protocole sécurisé HTTP, qui chiffre les échanges entre client et serveur via SSL/TLS, pour garantir la confidentialité et l’intégrité des données transmises. (voir section 8)

• Gestion des erreurs sécurisée : Technique consistant à renvoyer des messages d’erreur sans divulguer d’informations sensibles ou techniques susceptibles d’aider un attaquant, en évitant notamment la fuite de détails techniques ou de traces exploitables. (voir section 8)

• Limitation du taux de requêtes (rate limiting) : Mécanisme qui contrôle le nombre de requêtes qu’un client peut effectuer dans un laps de temps donné, afin de prévenir les attaques par déni de service (DoS) ou l’abus de l’API. (voir section 11)

📝 Points essentiels

• La validation des entrées est cruciale pour prévenir des vulnérabilités telles que l’injection SQL ou XSS, en contrôlant rigoureusement les données avant leur traitement (voir section 11).

• L’utilisation de HTTPS doit être systématique pour chiffrer tous les échanges, notamment lors de l’authentification et de la transmission de données sensibles, conformément aux recommandations de la section 8.

• La gestion des erreurs doit être pensée pour ne pas révéler d’informations techniques ou de traces internes, en renvoyant des messages d’erreur génériques ou structurés, ce qui limite la surface d’attaque (voir section 8).

• La limitation du taux de requêtes permet de protéger l’API contre les abus, les attaques par déni de service et d’assurer une disponibilité optimale pour tous les utilisateurs (voir section 11).

• Ces mesures doivent être intégrées dès la conception de l’API pour assurer une sécurité robuste et conforme aux bonnes pratiques.

💡 À retenir

La sécurité des API REST repose sur la validation rigoureuse des entrées, l’utilisation systématique de HTTPS, une gestion des erreurs prudente et la limitation du taux de requêtes pour prévenir les abus et garantir la confidentialité, l’intégrité et la disponibilité des services.

📖 8. Authentification & sécurité

🔑 Notions clés & Définitions

• Gestion des sessions et expiration : Mécanisme permettant de maintenir l’état d’authentification d’un utilisateur sur une période déterminée, avec une expiration automatique pour limiter le risque d’utilisation frauduleuse (voir aussi "Sécurisation des identifiants").
• Authentification (JWT, OAuth, token) : Processus permettant de vérifier l’identité d’un utilisateur ou d’une application via des mécanismes comme le JSON Web Token (JWT), OAuth ou l’utilisation de tokens, pour sécuriser l’accès aux ressources (voir aussi "Cryptographie pour protéger les données sensibles").
• Cryptographie pour protéger les données sensibles : Techniques de chiffrement et de hachage visant à assurer la confidentialité et l’intégrité des données critiques, notamment lors de leur stockage ou transmission, en utilisant des algorithmes sécurisés (voir aussi "Gestion des sessions et expiration").
• Sécurisation des identifiants : Ensemble des pratiques visant à protéger les identifiants d’accès (mots de passe, tokens) contre le vol ou la compromission, notamment par cryptographie, stockage sécurisé, et contrôle d’accès strict (voir aussi "Cryptographie pour protéger les données sensibles").
• Token (JWT) : Objet numérique utilisé pour authentifier une requête ou une session, contenant des informations encodées et signées, permettant une vérification rapide sans stockage côté serveur (voir aussi "Authentification").
• OAuth : Standard d’autorisation permettant à une application tierce d’accéder à des ressources protégées au nom d’un utilisateur, sans partager ses identifiants (voir aussi "Gestion des sessions et expiration").

📝 Points essentiels

• La gestion des sessions doit inclure une expiration automatique pour limiter la durée d’utilisation d’un token ou d’un cookie d’authentification, réduisant ainsi le risque d’abus en cas de vol (voir "Gestion des sessions et expiration").
• Les mécanismes d’authentification modernes, tels que JWT ou OAuth, permettent une authentification décentralisée et scalable, en évitant de stocker des sessions côté serveur, tout en garantissant la vérification de l’identité via des signatures cryptographiques (voir "Cryptographie pour protéger les données sensibles").
• La sécurisation des identifiants doit passer par le stockage crypté (ex : hash avec Argon2id), l’utilisation de protocoles chiffrés (HTTPS), et la limitation des tentatives pour prévenir les attaques par force brute (voir "Cryptographie pour protéger les données sensibles").
• La cryptographie joue un rôle clé dans la protection des données sensibles, notamment par le chiffrement des tokens, la signature des JWT pour garantir leur intégrité, et le stockage sécurisé des mots de passe (voir "Cryptographie pour protéger les données sensibles").
• La mise en œuvre correcte de ces mécanismes est essentielle pour prévenir les risques d’usurpation d’identité, de détournement de sessions, ou de fuite de données sensibles.

💡 À retenir

L’authentification sécurisée repose sur des mécanismes robustes comme JWT ou OAuth, combinés à une gestion rigoureuse des sessions, à la cryptographie pour protéger les données, et à une sécurisation stricte des identifiants. Ces pratiques assurent la confidentialité, l’intégrité et la disponibilité des accès.

📖 9. Vulnérabilités OWASP 2025

🔑 Notions clés & Définitions

• OWASP (Open Web Application Security Project, 2025) : Organisation à but non lucratif qui publie un Top 10 des vulnérabilités critiques pour orienter la sécurité des applications web et logicielles, en se concentrant sur les causes racines plutôt que sur les symptômes (voir introduction).
• Top vulnérabilités 2025 : Liste actualisée par OWASP qui identifie les risques majeurs affectant la sécurité des applications, notamment le contrôle d’accès défaillant, la mauvaise configuration, ou encore les défaillances cryptographiques (voir section 1.3).
• Vulnérabilité CWE (Common Weakness Enumeration, 2025) : Catalogue des faiblesses génériques dans le code, indépendantes d’un logiciel précis, permettant d’identifier des types de vulnérabilités récurrentes (voir vocabulaire).
• Vulnérabilité CVE (Common Vulnerabilities and Exposures, 2025) : Identification précise d’une vulnérabilité spécifique dans un logiciel ou une version donnée, avec un score de criticité (voir vocabulaire).
• Mishandling of Exceptional Conditions (2025) : Catégorie nouvelle qui regroupe les erreurs non gérées, comportements fail-open, et fuites d’informations dues à des exceptions mal traitées, pouvant entraîner des attaques comme SSRF ou déni de service (voir section 6.2).
• Cryptographic Failures (2025) : Défaillances dans l’utilisation ou la mise en œuvre du chiffrement, telles que le stockage en clair, l’utilisation d’algorithmes obsolètes ou l’absence de TLS, exposant des données sensibles (voir section 5.2).

📝 Points essentiels

• Évolution 2021-2025 : L’OWASP a recentré son Top 10 sur les causes racines, telles que la conception non sécurisée ou la mauvaise gestion des erreurs, plutôt que sur les symptômes. La catégorie "Security Misconfiguration" a gagné en importance, passant du 5e au 2e rang, notamment à cause des configurations cloud par défaut et des erreurs de déploiement.
• Nouvelles vulnérabilités majeures : La catégorie "Mishandling of Exceptional Conditions" introduit la problématique des erreurs non gérées, qui peuvent laisser des portes ouvertes aux attaques comme SSRF ou provoquer des dénis de service.
• Relations CWE et CVE : Un CWE représente une faiblesse générique (ex : CWE-89 pour injection SQL), tandis qu’un CVE désigne une vulnérabilité concrète dans un logiciel spécifique (ex : CVE-2021-44228 pour Log4Shell). La compréhension de cette relation permet d’anticiper et de corriger efficacement les failles.
• Importance de la prévention : La conception sécurisée, notamment via le threat modeling et le secure-by-design, est essentielle pour éviter des vulnérabilités coûteuses à corriger en production. La cryptographie doit être utilisée avec des algorithmes modernes comme Argon2id ou TLS 1.3 pour protéger les données sensibles.
• Détection et détection : La journalisation efficace, avec des logs contenant toutes les actions critiques, IPs, horodatages, et sans divulgation d’informations sensibles, est cruciale pour la détection rapide des incidents (voir sections 6.1 et 6.2).

💡 À retenir

Les vulnérabilités OWASP 2025 mettent en évidence l’importance de la conception sécurisée, de la détection proactive, et de la prévention des erreurs non gérées, afin de renforcer la résilience des applications face aux attaques modernes. La compréhension des causes racines et la mise en œuvre de bonnes pratiques cryptographiques sont clés pour réduire les risques.

📖 10. Contrôle d’accès défaillant

🔑 Notions clés & Définitions

• Contrôle d’accès défaillant : Situation où les règles de restriction d’accès aux ressources ne sont pas correctement appliquées, permettant à des utilisateurs non autorisés d’accéder à des fonctionnalités ou données sensibles. Selon OWASP (2021), il s’agit d’un défaut majeur où la gestion des permissions est insuffisante ou mal implémentée.
• Conséquences d’un contrôle d’accès mal implémenté : Elles incluent la divulgation d’informations confidentielles, la modification ou suppression non autorisée de données, et la possibilité pour un attaquant d’accéder à des fonctionnalités réservées à certains rôles. La mauvaise gestion peut entraîner des violations de la confidentialité, de l’intégrité, et de la disponibilité des systèmes.
• Exemples d’attaques liées au contrôle d’accès : Parmi celles-ci, l’IDOR (Insecure Direct Object Reference) où un utilisateur modifie un identifiant dans l’URL pour accéder à un autre compte, le SSRF (Server-Side Request Forgery) qui exploite la confiance du serveur pour accéder à des ressources internes, ou encore le accès admin sans autorisation via URL non protégée.

📝 Points essentiels

• La catégorie A01 — Broken Access Control dans le référentiel OWASP (2021, 2025) désigne une faille critique où les restrictions d’accès ne sont pas respectées, notamment avec l’intégration du SSRF dans cette catégorie en 2025.
• Le SSRF est une forme spécifique de contrôle d’accès défaillant où l’attaquant force le serveur à accéder à des ressources internes ou interdites, exploitant la confiance implicite accordée au serveur sur le réseau interne.
• La gestion inadéquate des identifiants ou des sessions, comme la fixation de session ou la non régénération après authentification, facilite la prise de contrôle de comptes (vulnérabilités A07 — Authentication Failures).
• La vulnérabilité IDOR permet à un utilisateur malveillant de modifier un paramètre dans l’URL pour accéder à des ressources qui ne lui sont pas destinées, en exploitant une absence de vérification côté serveur.
• La vérification du rôle ou des droits doit être systématique côté serveur, et non basée uniquement sur des paramètres côté client ou URL, pour éviter tout accès non autorisé.

💡 À retenir

Un contrôle d’accès défaillant permet à des utilisateurs non autorisés d’accéder ou de manipuler des ressources sensibles, ce qui peut entraîner des violations graves de sécurité. La prévention passe par une vérification systématique côté serveur, une gestion rigoureuse des identifiants, et la mise en place de mécanismes de protection contre des attaques comme l’IDOR ou le SSRF.

📖 11. Injection SQL & XSS

🔑 Notions clés & Définitions

• Injection SQL (voir section 12) : Désigne une vulnérabilité où un attaquant insère du code SQL malveillant dans une requête, pouvant entraîner la manipulation ou la divulgation non autorisée de données.
  AUTEUR (date) : Selon le CWE-89, l'injection SQL est une faiblesse où des entrées non filtrées permettent l'exécution de commandes SQL arbitraires.

• Cross-Site Scripting (XSS) : Vulnérabilité permettant à un attaquant d'injecter du code JavaScript malveillant dans une page web, qui sera exécuté par le navigateur d’un autre utilisateur, pouvant conduire à du vol de sessions ou à des manipulations de contenu.
  AUTEUR (date) : La vulnérabilité XSS est classée dans le CWE-79, représentant une faiblesse où l'entrée utilisateur n’est pas correctement échappée ou validée, permettant l’exécution de scripts non autorisés.

• Techniques de prévention des injections (voir section 12) : Méthodes visant à empêcher l’injection de code malveillant dans les requêtes SQL ou autres commandes, notamment l’utilisation de requêtes préparées, l’échappement des entrées, et la validation stricte des données.

• Techniques de prévention des XSS : Procédures pour éviter l’injection de scripts dans les pages web, telles que l’échappement des caractères spéciaux, l’utilisation de Content Security Policy (CSP), et la validation côté serveur des entrées utilisateur.

📝 Points essentiels

• L’injection SQL survient lorsque des entrées utilisateur non filtrées sont intégrées directement dans des requêtes SQL, permettant à l’attaquant d’exécuter des commandes arbitraires (CWE-89). Elle peut conduire à la fuite, modification ou suppression de données sensibles, voire à une prise de contrôle du serveur. La prévention repose principalement sur l’utilisation de requêtes préparées avec liaison de paramètres, évitant l’interprétation du contenu utilisateur comme du code SQL.

• Le XSS exploite la faiblesse de l’application à ne pas échapper ou valider correctement les entrées utilisateur affichées dans la page web. Il existe trois types principaux : XSS stocké, réfléchi et DOM-based. La prévention efficace inclut l’échappement systématique des données affichées, l’utilisation de Content Security Policy (CSP), et la validation côté serveur pour limiter les caractères spéciaux.

• La maîtrise des techniques de prévention est essentielle pour réduire la surface d’attaque. Pour l’injection SQL, l’usage de requêtes paramétrées est la meilleure pratique. Pour le XSS, l’échappement des caractères HTML et l’application de politiques de sécurité strictes sont recommandés.

• La relation entre ces vulnérabilités réside dans leur impact : toutes deux permettent l’exécution de code malveillant, mais dans des contextes différents (base de données pour SQL, navigateur pour XSS). Leur prévention repose sur une validation rigoureuse des entrées et une sortie contrôlée.

💡 À retenir

L’injection SQL et le XSS sont deux vulnérabilités majeures exploitant le manque de validation et d’échappement des entrées utilisateur, pouvant conduire à des fuites de données ou à la compromission de l’application. Leur prévention repose principalement sur l’utilisation de requêtes préparées et l’échappement systématique des données affichées.

📖 12. Cryptographie faible

🔑 Notions clés & Définitions

Cryptographie faible : Utilisation d’algorithmes ou de pratiques cryptographiques obsolètes ou mal adaptés, susceptibles d’être compromis par des attaquants, mettant en danger la confidentialité et l’intégrité des données. (Source : contexte général de sécurité)

Algorithmes obsolètes : Algorithmes cryptographiques dont la sécurité a été compromise ou qui présentent des vulnérabilités connues, tels que MD5 ou SHA1, et qui ne doivent plus être utilisés pour protéger des données sensibles. (Source : contexte général de sécurité)

Risques liés à l’utilisation d’algorithmes obsolètes : Exposition accrue aux attaques par collision, décryptage facilité, voire rupture totale de la confidentialité des données cryptées ou hachées. Par exemple, MD5 permet des collisions qui compromettent l’intégrité. (Source : contexte général de sécurité)

Bonnes pratiques pour choisir des algorithmes sécurisés : Favoriser l’utilisation d’algorithmes modernes et résistants, tels que Argon2id pour le hachage de mots de passe, TLS 1.3 pour les communications, et éviter les algorithmes rapides comme MD5 ou SHA1. Intégrer également l’usage de sels (salts) et de paramètres de coût ajustables pour renforcer la sécurité. (Source : contexte général de sécurité)

AUTEUR (date) : La résistance d’Argon2id repose sur sa consommation mémoire obligatoire, ce qui limite la capacité des GPU/FPGA à effectuer des attaques par force brute en utilisant des tentatives massives parallèles.

📝 Points essentiels

• La cryptographie faible résulte de l’utilisation d’algorithmes vulnérables ou obsolètes, tels que MD5, SHA1, ou des configurations inadéquates.
• Les algorithmes rapides comme MD5 ou SHA1 facilitent les attaques par collision ou force brute, compromettant la confidentialité et l’intégrité des données.
• La sélection d’algorithmes modernes, comme Argon2id pour le hachage de mots de passe, TLS 1.3 pour la sécurisation des communications, est essentielle pour garantir une sécurité robuste.
• La mise en œuvre correcte inclut l’usage de sels, de paramètres de coût ajustables, et une configuration sécurisée pour éviter toute vulnérabilité cryptographique.
• La compréhension des risques liés à l’utilisation d’algorithmes faibles permet d’adopter une stratégie de sécurité proactive et adaptée aux menaces actuelles.

💡 À retenir

L’utilisation d’algorithmes cryptographiques obsolètes ou mal configurés constitue une faille majeure, facilement exploitable par des attaquants, et doit être systématiquement évitée en privilégiant des pratiques et outils modernes, résistants et bien configurés.

📊 Tableaux de Synthèse

Aspect	Description	Auteur / Référence
Architecture MVC	Sépare Modèle (données), Vue (interface), Contrôleur (logique) pour une meilleure organisation du code	B2 - Architecture MVC
Rôle du Modèle	Gère la logique métier et l’accès aux données, interagit avec la base de données	Contenu source
Rôle de la Vue	Affiche les données, interface utilisateur, sans logique métier	Contenu source
Rôle du Contrôleur	Reçoit requêtes, valide, orchestre la manipulation des données, choisit la vue	Contenu source
Exemples MVC	Procedural simple, modulaire avec PDO, orienté objet avec classes	Contenu source
Avantages MVC	Séparation responsabilités, réutilisabilité, testabilité	Contenu source

⚠️ Pièges & Confusions Fréquentes

1. Confondre la Vue et le Contrôleur : la Vue ne doit contenir aucune logique métier, uniquement l’affichage.
2. Négliger la séparation Modèle/Contrôleur : tout mettre dans un seul fichier ou script complique la maintenance.
3. Oublier que le Modèle doit gérer l’accès à la base de données et la logique métier.
4. Confusion entre MVC procédural et orienté objet : ne pas mélanger les deux approches.
5. Sous-estimer l’importance de la modularité pour la sécurité et la réutilisabilité.
6. Mal comprendre le rôle du contrôleur comme orchestrateur, pas comme gestionnaire de la vue.
7. Confondre la logique métier et la présentation dans la Vue.

✅ Checklist Examen

• Connaître la définition de l’architecture MVC et ses composants (Modèle, Vue, Contrôleur) selon B2.
• Savoir différencier le rôle du Modèle, de la Vue et du Contrôleur.
• Être capable d’identifier un exemple de MVC procédural ou orienté objet.
• Connaître les avantages principaux du MVC : séparation, réutilisabilité, testabilité.
• Maîtriser les exemples concrets de mise en œuvre du MVC avec PHP (tableau, PDO, classes).
• Comprendre le principe de séparation des responsabilités pour faciliter la maintenance.
• Identifier les erreurs fréquentes comme la confusion entre Vue et Contrôleur ou la surcharge du modèle.
• Connaître la référence clé : B2 - Architecture MVC.
• Savoir comment le MVC facilite la gestion d’applications complexes.
• Être capable d’expliquer le rôle de chaque composant dans une architecture MVC.
• Maîtriser la différence entre MVC procédural et orienté objet.
• Vérifier la compréhension du rôle du contrôleur comme orchestrateur.