Skip to main content

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.

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 — 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 : 
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 
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. 
// 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 
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
server_tokens off;
more_clear_headers Server;

# Apache
ServerTokens Prod
ServerSignature Off

// 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 : 
// 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 : 
# 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 : 
// 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' })