← Documentation

Services de données exposés sur Internet

Une requête de lecture inoffensive vers les interfaces par défaut d'Elasticsearch, ClickHouse, Meilisearch, CouchDB et MongoDB ; signalé seulement si la réponse prouve qu'aucun identifiant n'a été demandé.

Méthode de contrôle

Une requête de lecture inoffensive vers les interfaces par défaut d'Elasticsearch, ClickHouse, Meilisearch, CouchDB et MongoDB ; signalé seulement si la réponse prouve qu'aucun identifiant n'a été demandé.

Type de preuve possible

Observation en ligne lorsque le contrôle est compatible et autorisé. Cette description ne signifie pas que votre plateforme a été testée.

Accès et limites

Adresse du site. Les résultats réels et les contrôles non exécutés figurent dans votre rapport. Un contrôle sans détection ne garantit pas l’absence de risque.

Situation concrète

Un service de recherche ou de données expose un point d’entrée sans restriction attendue.

Ce qu’il faut examiner

Déterminer si le contenu est public volontairement ou privé ; un port accessible ne prouve pas une fuite.

Approche de correction

Limiter l’exposition réseau et appliquer authentification et droits sur les données adaptés.

Comprendre les droits, les politiques et l’identité

Les droits de la base déterminent si un rôle peut atteindre une table ou une fonction ; la sécurité par ligne détermine les lignes accessibles. Activer RLS sans politique utilisable peut bloquer les utilisateurs, tandis qu’une politique trop large expose les autres comptes. Un identifiant serveur privilégié peut contourner ces protections et ne doit jamais atteindre le navigateur.

  1. Identifier le rôle de la requête et l’identité utilisée par la politique.
  2. Examiner les droits de table et les politiques pour chaque lecture ou écriture.
  3. Vérifier l’accès propriétaire aux éléments privés, brouillons et archives séparément de l’accès public.

Valider sans modifier les données de production

Une inspection du catalogue montre les définitions et droits, mais ne prouve pas tous les chemins d’accès applicatifs. Les exercices avec deux comptes apportent une preuve comportementale plus forte lorsqu’ils sont autorisés séparément. La présence d’une sauvegarde est aussi différente d’un test de restauration réussi.

  1. Examiner définitions et droits avec l’audit compatible en lecture seule.
  2. Utiliser des données isolées pour tout exercice comportemental autorisé.
  3. Revérifier l’accès propriétaire attendu et le refus entre comptes après les changements.

Références

OWASP A05

Sources et lectures complémentaires

Ces publications décrivent les pratiques et standards associés. Elles ne certifient pas votre plateforme et ne signifient pas que chaque méthode est exécutée par Hackaiz.