Exposition du stockage et des buckets

Méthode de contrôle

Buckets publics, objets listables et fichiers publics non voulus.

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 compartiment ou lien public rend des fichiers confidentiels lisibles.

Ce qu’il faut examiner

Distinguer ressources publiques voulues et fichiers privés, puis examiner liste, lecture et écriture séparément.

Approche de correction

Garder les objets confidentiels privés et utiliser droits limités ou liens temporaires si compatibles.

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 A01 · OWASP A05