Développer des composants métier coté serveur Flashcards
Comment se défendre contre une faille XSS ?
Prévention XSS➡️
- React protège nativement contre les XSS en transformant les données utilisateur en texte brut sécurisé avant leur insertion dans le DOM.
- Remplacer innerHTML par textContent/innerText. Ces 2 propriétés insèrent du texte brut sans interpréter de code HTML ou JavaScript.
- Encoder les données avant insertion dans le DOM➡️
Encodez les caractères spéciaux en entités HTML sécurisées, comme convertir < en < et > en >
Cela permet d’éviter l’interprétation de caractères dangereux tels que <, >, “, et ‘. - Valider les données pour vérifier si elle respecte les formats attendus➡️DOMPurify
- encodeURIComponent()➡️Encode 1 Chaine de caractère PR L’utiliser EN Toute Sécurité DS 1 URL
Comment se défendre contre une faille CRSF ?
- Utiliser des jetons CSRF (CSRF Tokens) ➡️Des jetons uniques et temporaires à CHQ requête de l’utilisateur PR vérifier que la requête provient bien du site légitime➡️ID A CHQ Requete
- Cookies avec l’attribut “SameSite”➡️ Les cookies peuvent être configurés pour ne pas être envoyés lors de requêtes provenant d’autre site➡️PAS Encore Présent Partout
- Configurer un CORS strict➡️Configurez les règles CORS pour n’accepter les requêtes que depuis des sites de confiance.
C’est quoi l’architecture MVC ?
L’architecture MVC est un modèle de conception qui divise une application en trois composants principaux pour séparer les responsabilités et faciliter la maintenance :
- Modèle➡️A=Fournit l’accès aux données
B=Communique avec la base de données. - Vue➡️A=Envoie des Données Formatées Au Client
B=Responsable de l’affichage des données à l’utilisateur.
C=Reçoit les données du modèle et les présente sous une forme visuelle (HTML, CSS…).
D=Besoin D’Aucun Dossier Spécifique. - Controlleur➡️A=Intermédiaire entre le Modèle et la Vue
B=Récupére les requêtes du client (formulaire), puis appele le modèle
C=Transmet les données reçues du Modèle à la Vue pour les présenter à l’utilisateur. - Exemple MVC :
A=L’utilisateur demande une page web (via HTTP GET OU POST).
B=Le Contrôleur reçoit la requête, interagit avec le Modèle pour obtenir des données.
C=Le Modèle renvoie les données au Contrôleur.
D=Le Contrôleur passe ces données à la Vue, qui génère la réponse visible par l’utilisateur (ex : une page HTML).
Dans le design pattern MVC, a-t’on un lien entre la partie M et la partie V ?
Dans le design pattern MVC, il n’y a pas de lien direct entre la partie Modèle (M) et la partie Vue (V). Toute interaction entre les deux passe par le Contrôleur (C), qui agit comme intermédiaire.
Cela irait contre la sépération des responsabilités.
Je souhaite retourner une réponse au client dans le cas où tout s’est bien passé. Quel status HTTP(s) je devrais utiliser ?
Quand une réponse au client c’est bien passé, on utilise un statut HTTP de la famille des 200 (succès).
Je souhaite retourner une réponse au client dans le cas où le serveur a rencontré une erreur. Quel status HTTP(s) je devrais utiliser ?
Dans le cas où le serveur a rencontré une erreur, vous devriez utiliser un statut HTTP de la famille des 500 (erreurs serveur).
Quel(s) intéret(s) y a-til de protéger les champs d’un formulaire côté backend (taille max d’un champ, complexité d’un password, …) étant donné qu’on peut faire toutes ces vérifications côté frontend (html/javascript) ?
Il ne faut jamais faire entièrement confiance aux données provenant du frontend. Les utilisateurs malveillant peuvent désactiver JavaScript ou manipuler les requêtes HTTP en utilisant des outils comme postman pour envoyer des données directement au serveur, contournant les validations frontend. Le backend doit agir comme un dernier rempart, notamment contre les injections SQL et le XSS.
Qu’est-ce qu’un test d’integration ?
Un test d’intégration est un type de test qui vérifie la bonne interaction entre plusieurs composants d’une application, afin de s’assurer qu’ils fonctionnent correctement ensemble.
Contrairement aux tests unitaires qui se concentrent sur des unités de code isolées, les tests d’intégration se concentrent sur la communication entre les composants.
EX :
1. Tester si un controlleur récupère bien l’ensemble des articles stockées dans la BDD.
Qu’est-ce qu’un test end to end ?
Un test end-to-end est un type de test qui vérifie le bon fonctionnement de l’application dans son intégralité, en simulant le parcours d’un utilisateur du début à la fin. Ce test englobe le frontend, le backend et la base de données, pour s’assurer que toutes les parties de l’application fonctionnent correctement ensemble.
Connaissez vous des outils permettant de contrôler la qualité du code que vous produisez ? En quoi ces outils sont particulièrement efficaces dans le cadre d’un travail en équipe ?
Outils pour contrôler la qualité du code :
- Eslint. Detecter les erreurs et les mauvaises pratiques dans le code.
- Prettier. Formate le code pour garantir un style cohérent, en évitant les débats sur l’apparence du code au sein d’une équipe.
EX : A=Prettier ajoute des espaces pour rendre le code plus lisible.
B= Les longues instructions sont automatiquement réorganisées pour être plus lisibles.
Pourquoi ces outils sont efficaces en travail d’équipe :
Standardisation du code :
Ils garantissent un style et des pratiques de code uniformes, facilitant la lecture et la compréhension du code par tous les membres de l’équipe.
Réduction des erreurs humaines :
Ils détectent automatiquement des problèmes.
Gain de temps :
Évite les débats inutiles en revue de code sur des questions de style ou de syntaxe, et permet de se concentrer sur le code.
C’est quoi un paradigme de programmation ?
Pouvez vous en lister 2 ?
Un paradigme de programmation est une approche de programation qui guide la manière dont les développeurs conçoivent, organisent et structurent leur code en fonction de principes et concepts spécifiques.
La programmation orientée objet (POO) est un paradigme qui organise le code autour de classes, comme une classe Voiture avec des attributs tels que marque et couleur, et des méthodes comme démarrer() ou accélérer(), permettant de structurer le code pour modéliser des objets du monde réel.
Exemples de langages : JavaScript, Java…
Dans la programmation événementielle, les événements, comme un clic sur un bouton, déclenchent des réactions spécifiques.
EX GEN : addEventListener()
Exemples de langages : JavaScript, Python…
Utilité de la POO ?
- Modularité et réutilisabilité du code :
La POO permet de diviser le code en classes et objets, rendant chaque partie réutilisable dans d’autres projets ou contextes.
Exemple : Une classe Voiture peut être réutilisée dans plusieurs applications.
- Facilité de maintenance :
Grâce à l’encapsulation, chaque objet est indépendant, ce qui rend le code plus facile à modifier sans impacter d’autres parties.
- Extension et évolution du logiciel :
Avec l’héritage, il est simple d’ajouter de nouvelles fonctionnalités en créant des sous-classes basées sur des classes existantes.
Exemple : Une classe Voiture peut être étendue en une classe VoitureÉlectrique pour ajouter des propriétés spécifiques.
En POO, quelle est la différence entre une classe et un objet ?
Une classe est un concept ou un plan général (Voiture).
Un objet est une entité spécifique créée à partir de ce concept
(Une Toyota rouge ou une Renault bleue).
Pouvez vous expliquer dans les grandes lignes comment fonctionne le système d’héritage en POO ?
A=Réutiliser une Class➡️Créer des NV Classes sur des Classes Existantes.
B=LA Classe Enfant Hérite des Propriétés DE LA Classe Parent
C=LA Classe Enfant Peut avoir de Nouvelles Propriétés ET Changer les Propriétes DU Parent
Une classe parent “Animal” avec des propriétés comme “nombre de pattes” et une méthode “se déplacer”. Une classe enfant “Oiseau” héritera de ces propriétés, mais pourra ajouter une nouvelle propriété comme “peut voler” et modifier la méthode “se déplacer” pour refléter qu’il vole au lieu de marcher.
L’héritage en POO permet à une classe d’utiliser les caractéristiques d’une autre classe, ce qui évite de réécrire du code déjà existant.
C’est quoi les CORS ?
Les CORS contrôle quels sites peuvent échanger des données entre eux pour des raisons de sécurité.
Les CORS (Cross-Origin Resource Sharing) sont un mécanisme de sécurité basé sur des en-têtes HTTP conçu pour contrôler l’accès au serveur selon l’origine des requêtes. Les CORS permet à un serveur de restreindre ou d’autoriser l’accès à ses données à une liste de domaines explicitement autorisés. En l’absence d’une configuration adéquate des CORS, les requêtes provenant d’une origine différente de celle du serveur seront bloquées par défaut par les navigateurs, pour des raisons de sécurité.
Exemple :
Un site web hébergé sur http://site1.com veut accéder à une API située sur http://api2.com. Par défaut, cette requête serait bloquée par le navigateur. Si le serveur de http://api2.com envoie l’en-tête suivant dans sa réponse :
Access-Control-Allow-Origin: http://site1.com
Le navigateur autorise la requête, et le site peut utiliser les données de l’API.
