Développer des composants d’accès aux données SQL et NoSQL

Question 1

Quel est l’acronyme de CRUD ?

Answer 1

• Create
• Read
• Update
• Delete

Question 2

Qu’est-ce que le CRUD ?

Answer 2

Le CRUD désigne les 4 principales opérations qu’il est possible de faire avec une données d’une manière générale en informatique. On peux créer (CRUD), lire (CRUD), mettre à jour (CRUD) et supprimer (CRUD) une donnée.

Dans le cadre du développement d’une application Web avec persistance des données, les opérations du CRUD sont la plupart du temps toutes utilsées pour manipuler des données stockées en base de données.

Question 3

Quel est l’acronyme de BREAD ?

Answer 3

• Browse
• Read
• Edit
• Add
• Delete

Question 4

Quelle est la différence entre le CRUD et le BREAD ?

Answer 4

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)

Question 5

Côté backend, comment peut on se défendre contre une injection SQL ?

Answer 5

Il existe plusieurs manières (qui peuvent se compléter) pour se protéger contre les injections SQL. Une des plus efficaces consiste à “prépaper” ses requêtes côté backend avant de les exécuter au niveau de la base de données.

La préparation consiste à analyser d’abord les données variables d’une requetes SQL (nom d’un utilisateur, mot de passe, …) pour détecter si ces données contiennent des codes SQL malicieux.

Des librairies fournissent une API complète pour préparer ses requêtes (par exemple le package natif PDO en PHP, ou encore le package node mysql2 en javascript/typescript). De tels outils utilisent par exemple les REGEX pour détecter si des scripts SQL malicieux se sont logés dans les paramètres lors de la préparation d’une requete.

Question 6

En quoi consiste une attaque par injection SQL ?

Answer 6

Supposons un site web dans lequel un utilisateur peut s’authentifier à l’aide d’un formulaire classique. Côté backend, la requête (non remplie) pourrait être :

SELECT * FROM user WHERE name = ‘’ AND pass = ‘’ ;

Une personne malveillante peut alors saisir en nom d’utilisateur ‘admin’. Et surtout, au lieu de saisir un mot de passe comme cela est attendu dans le champ “mot de passe”, saisir un texte contenant une requête SQL. Par exemple, elle pourrait saisir le code SQL “ ‘ OR ‘1’=’1 “. (d’où le nom de l’attaque : injection SQL)

La requete exécutée côté base de données serait alors :

SELECT * FROM user WHERE name = ‘admin’ AND pass = ‘’ OR ‘1’=’1’ ;

La requête retourne un résultat, malheureusement valide, au backend. Et selon comment est codé ce dernier, la personne malveillante peut alors être autorisée à accéder à l’espace d’administration du site.

Question 7

Connaissez vous un outil permettant de faire des analyses fines de pattern dans les chaines de caractères ?

Answer 7

Les REGEX permettent de faire cela. Les REGEX sont des motifs de recherches que l’on peut appliquer dans un texte et cela permet de détecter des pattern dans le texte voir d’extraires certaines données contenues dans un texte.

Les REGEX peuvent par exemple être utilisées pour vérifier si un mot de passe est suffisament complexe, ou encore pour détecter côté backend si un code malicieux a été inséré dans des données transmises par le frontend.

Les REGEX sont implémentées dans la plupars des langages de programmation (PHP, JS, Java, …)

Question 8

Je veux obtenir toutes les informations de tous les articles (table ‘article’) de ma BDD. Quelle requête SQL je dois exécuter ?

Answer 8

SELECT * FROM article;

Question 9

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 ?

Answer 9

SELECT title FROM article ORDER BY title ASC;

Question 10

Je veux obtenir le nombre total d’article (table ‘article’) de ma BDD. Quelle requête SQL je dois exécuter ?

Answer 10

SELECT COUNT(*) FROM article;

Question 11

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 ?

Answer 11

SELECT article.title
FROM article
JOIN author ON article.author_id = author.id
WHERE author.name = ‘admin’;

Question 12

Je veux insérer un nouvel article dans ma table article (champs : id, title). Quelle requête SQL je dois exécuter ?

Answer 12

En supposant que le champ ‘id’ est un INTEGER en AUTO_INCREMENT, il me suffit de faire :
INSERT INTO article (title) VALUES (‘vive les croissants !’);

Question 13

Je veux mettre à jour le titre de l’article dont l’id est 42. Quelle requête SQL je dois exécuter ?

Answer 13

UPDATE article SET title = ‘vive les croissants et les pains au chocolat !’ WHERE id = 42;

Question 14

Je veux supprimer l’article dont l’id est 1337. Quelle requête SQL je dois exécuter ?

Answer 14

DELETE FROM article WHERE id = 1337;

Question 15

Pouvez vous lister quelques grandes familles de type de test ?

Answer 15

Il existe par exemple les tests unitaires, les tests d’intégration et les tests end-to-end

Question 16

Qu’est-ce qu’un test unitaire ?

Answer 16

Un test unitaire teste une et une seule fonction (qui parfois appelle d’autres sous-fonctions). Il s’agit des tests les plus rapides à écrire et les plus facile à maintenir de part leur simplicitié. La fonction testée doit être déterministe : si je lui transmet toujours les mêmes paramètres dont elle a besoin, alors, elle renverra toujours le même résultat.

Un exemple de fonction non-déterministe pourrait être une fonction qui fait un appel vers une base de données. La base de données pouvant changer d’état indépendament de la volonté de la fonction, le résultat du traitement de la fonction peut alors varier (même en utilisant toujours les mêmes paramètres). La fonction n’est donc pas déterministe.

De par sa simplicité et sa proximite avec le code de l’application, un test unitaire est un test dit de “bas niveau” et doit être simple et stupide.

[ Il est possible, via un système de mockage de rendre une fonction non-déterministe en une fonction déterministe, mais là on tombe sur des concepts un peu avancés et qui sortent du cadre du titre ;) ]

Question 17

Au delà du fait que “c’est bien de tester son code” ; quel(s) intéret(s) y-a-t’il de prendre du temps à écrire, exécuter et maintenir (faire évoluer) des tests unitaires ?

Answer 17

Le code d’une application est amené à évoluer à diverses occasions : évolution d’une fonctionnalité, mise à jour d’un package externe, combler une faille de sécurité, opération de refactoring de code, …

Ces évolutions peuvent provoquer des bugs qui peuvent n’être détectés que très tardivement dans le cycle de vie d’une application. Or, plus un bug est détecté tardivement (par exemple : un bug détecté dans un environnement de production), plus il faudra consacrer de temps pour le résoudre.
Des tests unitaires, exécutés par exemple automatiquement dans une pipeline de CI (avec github par exemple), permettent de détecter au plus tôt une regression de l’application lorsqu’on la fait évoluer. Suite à l’exécution des tests unitaires, le développeur verra alors très rapidement quelle fonction pose problème, il pourra rapidement faire le lien entre le bug et les développements récents qu’il a effectué et ainsi résoudre rapidement et facilement l’anomalie.

Question 18

Qu’est-ce que la couverture de code dans le cadre des tests unitaires ?

Answer 18

La couverture de code (code coverage) est un indicateur qui permet de savoir quel pourcentage du code total de l’application est testé par des tests unitaires. La plupars des outils d’automatisation de test (PHPUnit, Jest, …) fournissent un rapport après l’exécution des tests automatiques et l’indicateur de couverture de code y est présent.

Plus le code coverage s’approche de 100%, plus l’application est robuste, mais aussi, plus le temps d’écriture et le temps de maintenance des tests devient important. Il n’est pas essentiel d’obtenir 100% de code coverage surtout dans le cadre d’une application non sensible (en fonction des impacts humains et/ou financiers concernés). Viser 60 à 80% de code coverage est une bonne fourchette pour un projet classique.

À noter qu’un code coverage de 100% ne signifie pas qu’on est protégé de tous les bugs malheureusement ;)

Question 19

Quelle est la différence entre un SGBDR et un SGBD NoSQL ?

Answer 19

Assurer la bonne cohérence des données fait partie des priorités d’un SGBD Relationnel “classique” (MySQL, MariaDB, PostgreSQL, …)

Les SGBD NoSQL ont été conçu pour être moins contraignants que les SGBD Relationnels classiques, ainsi les SGBD NoSQL utilisent très peu de containte d’intégrité (voir aucune). Cela apporte plus de flexibilité et une évolution plus facile de la structure des données persistées mais, en contrepartie, beaucoup moins de règles de vérification (contraintes d’intégrités) côté base de données. Les règles de vérifications sont alors déportées au niveau de l’applicatif (Symfony, Express, …)

Cependant, certains SGBD NoSQL comme MongoDB proposent des fonctionnalités qui se rapprochent de celles utilisées dans un SGBD Relationnel. MongoDB autorise par exemple (mais n’oblige pas) la création de clé étrangères entre deux tables (ou collections en MongoDB).

Question 20

Quel est l’acronyme de NoSQL ?

Answer 20

Not only SQL