Développer des composants d’accès aux données SQL et NoSQL Flashcards
Qu’est-ce que le CRUD ?
Le CRUD sont des opérations pour gérer les données dans une base de données.
Create (Créer) : Ajouter de nouvelles données.
Ex : Ajouter un utilisateur à une base de données.
Read (Lire) : Consulter ou récupérer les données existantes.
Ex : Afficher la liste des produits dans un catalogue.
Update (Mettre à jour) : Modifier des données existantes.
Ex : Changer l’adresse d’un client dans un système.
Delete (Supprimer) : Supprimer des données.
Ex : Effacer un compte utilisateur obsolète.
Qu’est-ce que le BREAD ?
Le BREAD est une extension du CRUD pour gérer les données avec 5 opérations:
Browse (Parcourir) : Afficher une liste d’éléments.
Ex : Afficher une table avec tous les articles d’un blog dans une interface de gestion.
Read (Lire) : Consulter un élément spécifique.
Ex : Voir les détails d’un article spécifique (titre, contenu, auteur).
Edit (Modifier) : Mettre à jour un élément existant.
Ex : Modifier le titre ou le contenu d’un article.
Add (Ajouter) : Créer un nouvel élément.
Ex : Ajouter un nouvel article au blog.
Delete (Supprimer) : Effacer un élément.
Ex : Supprimer un article du blog.
Quelle est la différence entre le CRUD et le BREAD ?
BREAD est une proposition d’amélioration du CRUD. Le principal apport du BREAD est de scinder l’opération R (Read) du CRUD en deux sous-opérations B et R dans le BREAD. L’opération B doit permettre de lire un ensemble de données, tandis que l’opération R doit permettre de lire qu’une donnée spécifique.
Dans le cadre d’un site Web utilisant une base de données :
Browse : doit retourner un ensemble d’entrées extraites de la base de données (exemple : retourner tous les articles du site)
Read : doit retourner une seule entrée extraite de la base de données (exemple : retourner l’article dont l’id est 42)
Côté backend, comment peut on se défendre contre une injection SQL ?
Lutter Contre l’Injection SQL :
Requêtes préparées (paramétrées) : Utilisez des requêtes préparées pour séparer le code SQL des données utilisateur.
ORM sécurisé : Adoptez un ORM, comme TypeORM ou Prisma, qui génère automatiquement des requêtes SQL sécurisées et réduit le risque d’erreurs manuelles.
Limiter les privilèges des utilisateurs de la base de données : Configurez le compte utilisé par l’application avec les privilèges strictement nécessaires.
Exemple : Interdire les suppressions ou modifications non requises pour minimiser les risques.
En quoi consiste une attaque par injection SQL ?
Une attaque par injection SQL consiste à insérer du code SQL malveillant dans une requête prévue pour interagir avec une base de données, dans le but d’exécuter des actions non autorisées, telles que voler, modifier ou supprimer des données, ou contourner des mécanismes de sécurité.
Supposons un site web où un utilisateur s’authentifie via un formulaire. Côté backend, une requête classique pourrait ressembler à ceci (avant d’être remplie avec les données utilisateur):
SELECT * FROM user WHERE name = ‘’ AND password = ‘’;
Une personne malveillante peut saisir “admin” comme nom d’utilisateur. Au lieu de fournir un mot de passe légitime, elle insère du code malveillant dans le champ mot de passe, comme OR ‘1’=’1’.
La requete exécutée côté base de données serait alors :
SELECT * FROM user WHERE name = ‘admin’ AND password
= ‘’ OR ‘1’=’1’;
Le OR ‘1’=’1’ rend la condition toujours vraie, permettant à la requête de renvoyer un utilisateur valide. Si le backend n’est pas sécurisé, cette personne pourrait être authentifiée et accéder à l’espace d’administration du site.
Je veux obtenir toutes les informations de tous les articles (table ‘article’) de ma BDD. Quelle requête SQL je dois exécuter ?
SELECT * FROM article;
Je veux obtenir les titres de tous les articles (table ‘article’) de ma BDD et trier le résultat par ordre alphabétique. Quelle requête SQL je dois exécuter ?
SELECT titre FROM article
ORDER BY titre ASC;
Je veux obtenir le nombre total d’article (table ‘article’) de ma BDD. Quelle requête SQL je dois exécuter ?
SELECT COUNT(*) FROM article;
Supposons deux tables ‘article’ (champs : id, title, author_id) et ‘author’ (champs : id, name). Je veux lister les titres de tous les articles écrits par l’auteur dont le ‘name’ est ‘admin’. Quelle requête SQL je dois exécuter ?
SELECT article.title
FROM article
INNER JOIN author
ON author.id = article.author_id
WHERE author.name = ‘admin’;
Je veux insérer un nouvel article dans ma table article (champs : id, title). Quelle requête SQL je dois exécuter ?
INSERT INTO article (id, title)
VALUES (1, ‘Mon premier article’);
Je veux mettre à jour le titre de l’article dont l’id est 42. Quelle requête SQL je dois exécuter ?
UPDATE article
SET title = ‘Nouveau titre’
WHERE id = 42;
Je veux supprimer l’article dont l’id est 1337. Quelle requête SQL je dois exécuter ?
DELETE FROM article
WHERE id = 1337;
Pouvez vous lister quelques grandes familles de type de test ?
Les grandes familles de types de tests incluent :
1.Tests unitaires (vérification des composants isolés)
2. Tests d’intégration (interactions entre modules)
3. Tests fonctionnels (vérification des fonctionnalités selon les spécifications)
4. Tests de performance (analyse des temps de réponse et de charge)
5. Tests de sécurité (évaluation des vulnérabilités)
6. Tests end-to-end (validation du fonctionnement complet d’une application du début à la fin).
Qu’est-ce qu’un test unitaire ?
Un test unitaire est un test qui vérifie de manière isolée le bon fonctionnement d’un morceau de code, comme une fonction, en s’assurant qu’il retourne les résultats attendus.
Utilité des tests unitaires ?
Les tests unitaires présentent plusieurs intérêts essentiels:
- Détection rapide des erreurs : Ils permettent d’identifier rapidement les bugs dans des parties spécifiques du code, facilitant leur correction avant qu’ils n’impactent l’ensemble du système.
- Confiance dans les refactorisations : Lorsqu’on modifie le code,
les tests unitaires assurent que les changements n’ont pas perturbé les fonctionnalités existantes. - Gain de temps à long terme : Bien que l’écriture initiale des tests prenne du temps, leur utilisation réduit les efforts nécessaires pour trouver et résoudre les bugs lors des phases ultérieures du développement.
