> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qaos.machdel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Divulgation d'information
> Fichiers de configuration exposés, messages d'erreur verbeux, en-têtes de version du serveur et données de débogage qui aident les attaquants à cartographier votre système.
Les vulnérabilités de divulgation d'information ne compromettent pas directement votre application, mais elles donnent aux attaquants les données de reconnaissance dont ils ont besoin pour planifier des attaques ciblées. Un fichier `.env` exposé, une trace de pile dans une page 500 ou un en-tête `Server: Apache/2.4.51` peut être le point de départ d'un exploit critique.
***
## exposed-sensitive-file
Critique
**Description**
Des fichiers sensibles — tels que `.env`, `config.json`, `backup.sql`, `.git/config` ou `phpinfo.php` — sont accessibles publiquement via une URL directe, ou la liste des répertoires est activée sur le serveur, exposant la liste complète des fichiers.
**Importance**
Les fichiers `.env` contiennent souvent des identifiants de base de données, des clés API et des secrets de chiffrement. Un seul fichier `.env` exposé donne à un attaquant tout ce dont il a besoin pour compromettre votre infrastructure. Les listes de répertoires exposent la structure complète de l'application, rendant les attaques ultérieures triviales.
**Comment QAOS le détecte**
L'agent sonde un ensemble de chemins de fichiers sensibles courants sur chaque cible :
```
/.env
/backup.sql
/.git/config
/phpinfo.php
/config.json
/credentials.json
/wp-config.php
/.DS_Store
```
Il vérifie également si la liste des répertoires est activée en demandant directement des URLs de répertoires.
**Comment corriger**
Configurez votre serveur web pour refuser l'accès aux fichiers sensibles :
```nginx theme={null}
# Nginx — refuser l'accès aux fichiers avec point et chemins sensibles
location ~ /\. {
deny all;
}
location ~* \.(env|sql|bak|config)$ {
deny all;
}
```
Désactivez la liste des répertoires :
```nginx theme={null}
autoindex off;
```
Utilisez `.gitignore` et `.dockerignore` pour vous assurer que `.env` et autres secrets ne sont jamais placés dans des répertoires publics.
***
## sensitive-data-logged
Élevé
**Description**
La console du navigateur contient des entrées de journal avec des informations sensibles : mots de passe, jetons d'authentification, jetons JWT, clés API ou informations personnellement identifiables (PII).
**Importance**
Les journaux de console du navigateur sont visibles pour tout utilisateur avec les DevTools ouverts. Dans les environnements partagés ou quand un utilisateur partage une capture d'écran, ces données sont exposées. Les journaux de console se propagent aussi souvent vers des systèmes d'agrégation de journaux, créant un enregistrement persistant de données sensibles.
**Comment QAOS le détecte**
L'agent capture les entrées de journal de console pendant l'interaction normale avec la page et les analyse pour détecter des motifs indiquant des données sensibles : chaînes de mot de passe, motifs de jeton, numéros de carte de crédit, motifs de numéro de sécurité sociale, ou objets utilisateur complets contenant des PII.
**Exemples**
```javascript theme={null}
console.log('Utilisateur connecté :', { email: 'user@example.com', password: 'hunter2' })
console.log('Jeton auth :', authToken)
console.log('Réponse :', { creditCard: '4111-1111-1111-1111' })
```
**Comment corriger**
Auditez tous les appels `console.log` avant le déploiement en production. Utilisez une bibliothèque de journalisation qui supporte les niveaux de journaux et nettoie ou rédige automatiquement les champs sensibles. Ne journalisez jamais les valeurs de mot de passe, les jetons complets ou les objets utilisateur complets contenant des PII.
```javascript theme={null}
// Utiliser la journalisation structurée avec rédaction des champs
logger.info('Utilisateur connecté', { userId: user.id, email: user.email })
// PAS : logger.info('Utilisateur connecté', user) — peut inclure le hachage de mot de passe, jetons, etc.
```
***
## server-info-leakage
Moyen
**Description**
Les en-têtes de réponse HTTP divulguent le nom du logiciel serveur et le numéro de version exact, donnant aux attaquants une liste ciblée de CVE connus à exploiter.
**Importance**
Un attaquant qui sait que vous exécutez `Apache/2.4.51 (Ubuntu)` peut immédiatement rechercher toutes les vulnérabilités connues pour cette version et tenter des exploits ciblés. Les informations de version sont une reconnaissance gratuite.
**Comment QAOS le détecte**
L'agent vérifie les en-têtes de réponse HTTP pour les valeurs `Server` et `X-Powered-By` qui incluent des numéros de version ou des noms de frameworks.
**Exemples**
```http theme={null}
Server: Apache/2.4.51 (Ubuntu) ← version exacte divulguée
X-Powered-By: PHP/7.4.3 ← version PHP
X-Powered-By: Express ← framework backend
X-Powered-By: ASP.NET ← pile technologique
```
**Comment corriger**
Supprimez ou généralisez les en-têtes d'identification du serveur :
```nginx theme={null}
# Nginx
server_tokens off;
more_clear_headers Server;
```
```apache theme={null}
# Apache
ServerTokens Prod
ServerSignature Off
```
```javascript theme={null}
// Express.js
app.disable('x-powered-by')
```
***
## detailed-error-message
Moyen
**Description**
La console du navigateur contient des traces de pile, des chemins du système de fichiers, des messages d'erreur de base de données ou des adresses IP internes qui révèlent la structure interne de l'application.
**Importance**
Les traces de pile révèlent les chemins de fichiers et les numéros de ligne, permettant aux attaquants de cartographier la base de code. Les erreurs de base de données comme `SQLSTATE[42S02]: Table 'users' not found` exposent les détails du schéma. Les adresses IP internes révèlent la topologie du réseau.
**Comment QAOS le détecte**
L'agent capture toutes les entrées de journal de console et les analyse pour détecter des motifs de trace de pile, des chaînes d'erreur de base de données, des chemins du système de fichiers et des adresses réseau internes.
**Exemples**
```
at /var/www/app/routes/user.js:42:15
SQLSTATE[42S02]: Table 'users.sessions' doesn't exist
Traceback (most recent call last): File "/app/api/views.py", line 128
Connection refused: 192.168.1.5:5432
```
**Comment corriger**
Mettez en place un middleware de gestion des erreurs approprié qui journalise les erreurs détaillées **uniquement côté serveur**, tout en envoyant des messages d'erreur génériques au client. Configurez votre framework de journalisation pour écrire dans des fichiers, pas vers des sorties visibles par le navigateur :
```javascript theme={null}
// Gestionnaire d'erreurs Express.js
app.use((err, req, res, next) => {
logger.error(err) // journal détaillé côté serveur
res.status(500).json({ error: 'Une erreur inattendue s\'est produite' }) // réponse générique au client
})
```
***
## detailed-error-page
Moyen
**Description**
Les pages d'erreur (404, 500, etc.) affichent des traces de pile, des chemins de fichiers, des messages d'erreur de base de données ou des adresses IP internes au lieu d'un message d'erreur générique.
**Importance**
Les pages d'erreur sont souvent les pages à la plus haute densité d'informations dans une application. Une page d'erreur 500 verbeuse peut révéler l'ensemble de la pile de l'application, le schéma de base de données et la disposition du réseau interne en une seule réponse.
**Comment QAOS le détecte**
L'agent demande délibérément des pages inexistantes et déclenche des erreurs serveur pour sonder la verbosité des pages d'erreur, vérifiant la réponse pour des traces de pile et des détails internes.
**Comment corriger**
Configurez des pages d'erreur personnalisées qui n'affichent qu'un message convivial sans aucun détail interne. En développement, les erreurs verboses sont utiles — mais assurez-vous que `DEBUG=False` (ou équivalent) en production :
```python theme={null}
# Django
DEBUG = False # Jamais True en production
# FastAPI — utiliser des gestionnaires d'exceptions
@app.exception_handler(Exception)
async def generic_exception_handler(request, exc):
logger.exception(exc)
return JSONResponse(status_code=500, content={"detail": "Erreur interne du serveur"})
```
***
## local-log-storage
Moyen
**Description**
Le JavaScript côté client écrit des entrées de journal dans `localStorage` ou `sessionStorage`, persistant des données de débogage dans le navigateur à travers les sessions.
**Importance**
`localStorage` est accessible à tout JavaScript s'exécutant sur la même origine (y compris les scripts injectés via XSS) et persiste indéfiniment. Des données de débogage sensibles stockées là peuvent être lues par des attaquants longtemps après la session originale.
**Comment QAOS le détecte**
L'agent analyse le code source JavaScript pour détecter les appels à `localStorage.setItem` ou `sessionStorage.setItem` avec des motifs liés aux journaux.
**Comment corriger**
Supprimez la journalisation basée sur localStorage des builds de production. Si vous avez besoin de rapports d'erreurs côté client, utilisez un service approprié (Sentry, Datadog) qui transmet les journaux via HTTPS plutôt que de les stocker localement.
***
## log-event-exposure
Faible
**Description**
L'application émet des événements de journal vers la console du navigateur en production, exposant des détails d'implémentation à tout utilisateur qui ouvre les DevTools.
**Importance**
Bien que moins critique que les traces de pile, la sortie de débogage console révèle des motifs d'appels API, l'état interne, les drapeaux de fonctionnalités et le comportement de l'application qui aide les attaquants à comprendre votre système.
**Comment QAOS le détecte**
L'agent capture toute la sortie console pendant l'interaction normale avec la page et vérifie les instructions console non-erreur qui semblent être de la journalisation au niveau débogage.
**Comment corriger**
Utilisez une bibliothèque de journalisation qui respecte les niveaux de journaux et désactive la sortie de débogage en production :
```javascript theme={null}
// Utiliser une condition basée sur l'environnement
if (process.env.NODE_ENV === 'development') {
console.log('[Debug]', data)
}
// Ou utiliser un logger avec filtrage par niveau
const logger = createLogger({ level: process.env.LOG_LEVEL || 'warn' })
```