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 contrôle d’accès permettent aux attaquants d’agir en dehors de leurs permissions prévues. Elles sont systématiquement classées comme le risque n°1 des applications web par l’OWASP et peuvent mener à un accès non autorisé aux données, une prise de contrôle de compte et une compromission complète de l’application.

​
unauthenticated-resource-access

Critique Description Une ressource qui devrait nécessiter une authentification est accessible sans aucun identifiant. Cela inclut les tableaux de bord, les pages de compte, les panneaux d’administration et les endpoints API qui retournent des données sensibles. Importance Un attaquant qui découvre une route non protégée peut accéder aux données utilisateurs, aux fonctions administratives ou à l’état sensible de l’application sans avoir besoin de se connecter. Comment QAOS le détecte L’agent identifie les pages qui semblent nécessiter une authentification, puis ouvre une nouvelle session de navigateur non authentifiée et navigue directement vers ces pages. Si la page se charge normalement au lieu de rediriger vers la connexion, le problème est confirmé. Exemple 
GET /dashboard HTTP/1.1
Host: app.example.com
# Aucun cookie de session ni en-tête Authorization

HTTP/1.1 200 OK  ← devrait être 401 ou une redirection vers /login
Comment corriger Implémentez des vérifications d’authentification côté serveur sur chaque route protégée. Ne vous fiez jamais uniquement au routage côté client. Pour les APIs, exigez un jeton de session valide ou un JWT sur chaque endpoint retournant des données non publiques. Utilisez un middleware qui applique l’authentification par défaut, avec un opt-out explicite pour les routes publiques.

​
privilege-escalation

Critique Description Un utilisateur peut effectuer des actions ou accéder à des ressources nécessitant des privilèges supérieurs à ceux qui lui ont été accordés. Par exemple, un utilisateur ordinaire accédant aux fonctions d’administration, ou modifiant les données d’un autre utilisateur. Importance L’escalade de privilèges permet aux attaquants d’élever leur accès sans contourner l’authentification. Les vecteurs d’attaque courants incluent la modification de paramètres de formulaire cachés, la modification des IDs utilisateur dans les requêtes API, ou la devinette d’URLs admin. Comment QAOS le détecte L’agent recherche des interfaces d’administration, des boutons d’actions privilégiées ou des formulaires manipulant des données sensibles. Il tente ensuite une altération des paramètres de rôle (ex. : ajout de ?role=admin ou isAdmin=true) et essaie d’exécuter des actions privilégiées en tant qu’utilisateur ordinaire. Exemples 
POST /api/users/update
{"userId": "456", "role": "admin"}   ← altération du champ rôle

GET /admin/delete-user?id=123        ← endpoint admin accessible à un utilisateur ordinaire
Comment corriger Appliquez des vérifications d’autorisation côté serveur pour chaque action. Ne faites jamais confiance aux valeurs de rôle, privilège ou ID utilisateur fournies par le client. Utilisez une couche d’autorisation centralisée (ex. : politiques RBAC/ABAC) et vérifiez explicitement que l’utilisateur authentifié a la permission pour chaque opération demandée.

​
access-control-method-bypass

Critique Description Un endpoint applique le contrôle d’accès uniquement pour des méthodes HTTP spécifiques (ex. : POST) mais pas pour d’autres (ex. : GET, PUT). Un attaquant peut contourner la vérification en changeant la méthode HTTP. Importance De nombreux frameworks routent GET et POST vers le même gestionnaire avec une logique d’accès différente. Si la vérification d’autorisation est liée à une méthode spécifique, envoyer la même requête avec une méthode différente peut la contourner entièrement. Comment QAOS le détecte L’agent intercepte les requêtes API effectuées pendant la navigation normale, puis les rejoue avec différentes méthodes HTTP pour vérifier si la vérification d’autorisation est spécifique à une méthode. Exemple 
DELETE /api/admin/users/123
Authorization: Bearer regular-user-token

HTTP/1.1 200 OK  ← DELETE a contourné la vérification auth uniquement pour POST
Comment corriger Appliquez les vérifications d’autorisation basées sur la ressource et l’action demandée, pas sur la méthode HTTP. Votre middleware d’autorisation côté serveur doit s’exécuter pour toutes les méthodes sur les routes protégées.

​
forced-browsing-direct-url-access

Critique Description Un attaquant navigue directement vers une URL contenant un identifiant de ressource prévisible ou devinable pour accéder à des ressources appartenant à d’autres utilisateurs. Également connu sous le nom de Référence directe à un objet non sécurisée (IDOR). Importance Si votre application utilise des IDs numériques séquentiels ou des UUIDs prévisibles dans les URLs et ne vérifie pas que l’utilisateur demandeur possède la ressource, tout utilisateur authentifié (ou non authentifié) peut itérer à travers les IDs pour accéder ou extraire des données. Comment QAOS le détecte L’agent identifie les URLs contenant des paramètres d’ID (ex. : /user/123, /order/456), devine des identifiants adjacents et tente d’accéder à ces ressources. Il sonde également des chemins prévisibles comme /admin/config ou /api/users/all. Exemples 
GET /user/123/profile    ← requête légitime de l'utilisateur 123
GET /user/124/profile    ← utilisateur 123 accédant au profil de l'utilisateur 124 (IDOR)

GET /admin/config        ← devinette directe d'URL vers la configuration admin
Comment corriger Vérifiez toujours côté serveur que l’utilisateur authentifié a la permission d’accéder à l’ID de ressource spécifique demandé. Utilisez des identifiants non séquentiels et difficiles à deviner (ex. : UUIDs v4) quand c’est possible. Implémentez des vérifications d’autorisation au niveau des objets, pas seulement l’authentification au niveau des routes. 
# Vérifier la propriété avant de retourner les données
if resource.owner_id != current_user.id:
    raise HTTPException(status_code=403)