Introduction
Une application peut fonctionner correctement tout en révélant des informations inutiles à ses utilisateurs. DeskLite fonctionne déjà, mais sa réponse d’état contient des détails internes de développement. Vous allez examiner cette réponse, modifier un réglage et confirmer que le service reste utile.
Il suffit de savoir naviguer dans les répertoires et lire des fichiers dans un terminal. Requêtes, réponses HTTP, réglages et commande de redémarrage sont expliqués au moment de leur utilisation. Voici votre première boucle DevSecOps : observer un risque, en corriger la cause et vérifier à la fois la sécurité et le fonctionnement normal.
Observer et Corriger la Réponse d’un Service
Dans cette étape, vous lirez une réponse de DeskLite, identifierez les détails internes inutiles et corrigerez le réglage qui les expose.
DeskLite est une petite application d’assistance. Le personnel a besoin des tickets et d’une indication simple du fonctionnement du service, pas des emplacements internes de fichiers ni des diagnostics de développement. Ces détails sont les informations à protéger ; les personnes pouvant lire une réponse constituent son public.
Un service est un programme qui continue de fonctionner et répond aux requêtes. Une requête HTTP demande quelque chose à un service web ; la réponse contient un code d’état et un corps. Vous utiliserez curl dans le terminal, sans navigateur ni connaissances en programmation.
Le service est déjà prêt. Travaillez uniquement dans son répertoire :
cd /home/labex/project/desklite
Une URL indique à curl où envoyer la requête. Dans http://127.0.0.1:8080/status, http est le protocole, 127.0.0.1 désigne cette machine de laboratoire, 8080 sélectionne le service et /status un point de terminaison, une réponse particulière fournie par celui-ci. Aucune configuration réseau n’est nécessaire ici.
curl http://127.0.0.1:8080/status
Le corps utilise JSON : des champs nommés et leurs valeurs entre accolades. Vous devez seulement le lire, sans écrire de programme.
{
"service": "DeskLite",
"status": "running",
"internal_path": "/opt/labex-desklite/private/settings.ini",
"debug_details": "development diagnostics enabled"
}
service et status sont utiles au public prévu. internal_path révèle un emplacement interne et debug_details des informations de développement. Connaître un chemin ne donne pas automatiquement accès au fichier, mais des détails superflus peuvent aider à préparer d’autres investigations. Il s’agit d’une divulgation d’informations.
Ajoutez l’option -i pour afficher les en-têtes HTTP au-dessus du corps :
curl -i http://127.0.0.1:8080/status
La première ligne contient 200 OK : la requête a réussi. Les en-têtes comme Content-Type: application/json décrivent le corps ; une ligne vide les sépare. Les dates peuvent varier. Un succès HTTP ne garantit pas une réponse sûre : ici, la réponse réussie divulgue des informations.
Lisez la configuration du service, le fichier de réglages utilisé par l’application :
cat service.conf
[service] regroupe les réglages. Une ligne commençant par # est un commentaire explicatif. debug = true est un interrupteur booléen : true active les diagnostics de développement et false les désactive. Le commentaire relie ce réglage aux champs exposés.
Appliquer la Correction de Configuration
Les informations de débogage aident les développeurs à examiner les problèmes. Un réglage utile pendant le développement peut être inadapté à un public qui veut seulement un état public. DevSecOps intègre la sécurité au travail commun du développement et de l’exploitation : définir ce qui doit être visible, modifier la configuration et tester le résultat réel.
Ouvrez la configuration avec nano, un éditeur de texte pour terminal. Utilisez les flèches pour atteindre le réglage. Pour les raccourcis suivants, maintenez Ctrl enfoncée en appuyant sur la lettre :
nano service.conf
Remplacez uniquement debug = true par debug = false. Conservez l’en-tête [service] et le commentaire. Enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Vérifiez le fichier enregistré :
cat service.conf
Il doit maintenant contenir :
[service]
## Include development diagnostics in status responses.
debug = false
Le fichier sur disque et le programme en cours d’exécution sont distincts. Ce service lit ses réglages au démarrage : enregistrer ne modifie donc pas sa réponse. Le cours fournit restart.sh pour appliquer la configuration sans gérer les processus. bash exécute ce script préparé ; vous n’avez pas à le modifier.
bash restart.sh
Sortie attendue :
DeskLite restarted.
Interrogez de nouveau le même point de terminaison avec les en-têtes :
curl -i http://127.0.0.1:8080/status
Vous devez obtenir 200 OK et ce corps :
{
"service": "DeskLite",
"status": "running"
}
Les deux champs internes ont disparu, tandis que l’état utile est conservé. S’ils restent présents, vérifiez que vous avez enregistré service.conf et exécuté le redémarrage. Si le script signale une erreur de configuration, restaurez l’en-tête et l’orthographe du booléen montrés ci-dessus, puis réessayez. Ne remplacez pas l’application et n’arrêtez pas le service pour masquer sa réponse.
Vérifier Ensemble la Sécurité et le Métier
Dans cette étape, vous vérifierez que la correction résiste à un nouveau redémarrage et que DeskLite sert toujours ses utilisateurs.
Casser le service supprimerait la réponse, mais aussi ses fonctions utiles. Deux preuves sont donc nécessaires : les champs sensibles sont absents et le service légitime fonctionne encore. Un contrôle de santé indique la disponibilité de base ; une requête métier teste la fonctionnalité réellement nécessaire aux utilisateurs.
Redémarrez encore pour confirmer la persistance du réglage enregistré :
bash restart.sh
Vérifiez de nouveau l’état :
curl -i http://127.0.0.1:8080/status
Attendez-vous à 200 OK, service et status, sans internal_path ni debug_details. Interrogez le point de terminaison de santé :
curl -i http://127.0.0.1:8080/health
Résultat attendu : 200 OK et :
{
"status": "ok"
}
Interrogez enfin le point de terminaison métier :
curl -i http://127.0.0.1:8080/tickets
Résultat attendu : 200 OK et le ticket initial :
{
"tickets": [
{
"id": 1,
"title": "Printer offline"
}
]
}
Un processus sain ne prouve pas à lui seul que l’accès aux tickets fonctionne. Ensemble, ces requêtes montrent la suppression de la divulgation et le maintien de la fonctionnalité. curl peut aussi afficher une progression du transfert ; évaluez l’état HTTP et le corps, pas cet indicateur.
Avant de terminer, expliquez pourquoi 200 OK seul ne prouve pas la sécurité et pourquoi un contrôle de santé seul ne prouve pas le fonctionnement métier. Cette réflexion sert à comprendre ; aucun écrit n’est à rendre.
Résumé
Vous avez utilisé curl et curl -i pour lire une réponse HTTP, distingué une requête réussie d’une réponse sûre et relié les champs exposés à un réglage booléen. Vous avez enregistré ce réglage, redémarré DeskLite et confirmé le fonctionnement de l’état, de la santé et des tickets sans diagnostics internes.
Vous avez vérifié la configuration réelle et le service en fonctionnement, y compris après un nouveau redémarrage. Ce petit parcours relie réglages de développement, comportement opérationnel et vérification de sécurité. Le prochain défi applique les mêmes compétences à un autre service préparé.
