TS06Accès et indexation
Accès et indexationLes contenus privés sont-ils réellement protégés ?
Préparer une vérification d’accès utile à votre équipe technique.
Préparer mon test d’accès
- Dans l’app
- Préparation du test d’accès
- À fournir
- URL privée et rôles autorisés
- À prévoir
- Lecture et confirmation
À fournir
À prévoirComprendre
Un contenu privé. Un accès maîtrisé.
Préparer une vérification d’accès utile à votre équipe technique.
Critère du protocole TSEP
TSEP distingue le plan de protection et les preuves d’un accès réellement refusé. Une URL non indexée n’est pas une preuve de confidentialité.
Les règles et limites de ce contrôle sont détaillées en bas de fiche.
Vérifier
Chaque rôle. Chaque accès.
Dans TSEP Control
Un plan de test copiable et téléchargeable. Aucun verdict d’accès réel : le moteur actuel ne qualifie que des traces synthétiques.
Votre contribution
Une URL privée, les personnes autorisées, le contenu à protéger et le refus attendu.
Avec vos outils
Avec vos outilsSur un environnement et des comptes autorisés, vérifiez l’accès sans connexion puis avec chaque rôle prévu. Contrôlez aussi les fichiers et réponses API, et conservez des preuves expurgées de tout secret.
Ce que ce résultat couvre
Ce parcours prépare un test : aucune requête anonyme n’est envoyée et aucun accès réel n’est prouvé. Robots.txt ou noindex ne protègent pas un contenu privé.
Agir
Le serveur décide. Le contenu reste privé.
Faites appliquer le refus d’accès côté serveur, puis faites tester chaque rôle non autorisé.
Recontrôler
Les droits changent. Rejouez les accès.
Reprenez le parcours avec le même périmètre après correction. Datez la nouvelle observation et conservez les preuves précédentes.
Pour aller plus loin.
Les statuts, les sources et la méthode.
Comprendre les statutsC · NC · NT · NA
La même légende dans les fiches, l’analyse et la démo. Chaque statut dépend des preuves et des règles du contrôle.
- C · Vérifié
- Le critère est satisfait dans le périmètre évalué. Conservez la preuve datée pour la prochaine comparaison.
- NC · À corriger
- Faites appliquer le refus d’accès côté serveur, puis faites tester chaque rôle non autorisé.
- NT · Non établi
- Les preuves ou les confirmations ne suffisent pas pour conclure. Complétez ce qui manque ; ce statut ne démontre pas une erreur SEO.
- NA · Non applicable
- Le contrôle ne s’applique pas au périmètre, selon ses règles et une justification conservée. Une absence de preuve ne suffit pas à le déclarer non applicable.
Sources et références4 références
Méthode et règles détaillées1 règle
Méthode et critères du contrôle
Méthode
Avant les observations, fournir intent.ts06_access et son empreinte liée à configuration.ts06_access. Déclarer routes, marqueurs synthétiques, rôles fictifs, tests exacts par route/rôle et triplets froid anonyme → amorçage autorisé synthétique → rejeu anonyme, avec même étiquette de cache. Examiner les GET fournis sans résolution DNS ni requête réseau. Les redirections d’authentification doivent rester sur la même origine (schéma, hôte, port effectif) et suivre une liste de chemins explicitement déclarée. Une réponse 404 ne compte comme refus que si le plan la déclare pour cette route.
Critères attendus
Pass signifie seulement que toutes les cellules route/rôle non autorisées déclarées sont complètes, refusées sans marqueur sensible et que chaque triplet fourni suit l’ordre déclaré sans fuite au rejeu ; le contrôle ne mesure ni une identité réelle ni un cache réel. Toute réponse attribuable à un rôle non autorisé contenant un canari échoue, y compris un corps encodé détecté ou un en-tête de réponse. Une représentation 2xx livrée à un rôle non autorisé échoue aussi.
Non-applicabilité
Le contrôle entier peut être NA seulement avec une revue d’inventaire synthétique complète, datée et motivée qui déclare aucune route sensible dans le périmètre ; aucun test ni triplet contradictoire ne peut alors être présent.
Règles détaillées
TS06-A01 · Accès refusé dans la matrice HTTP synthétique fournie
Mode prévu par le protocole : assisté, avec preuves et déclarations fournies. La disponibilité dans l’app est indiquée sur la fiche du contrôle.
Périmètre
Au moins une route sensible est explicitement déclarée dans le périmètre synthétique.
Preuves
Records configuration/intent/http liés à la cible, empreinte du plan, routes/rôles/tests, échanges GET bruts avec horodatages, canaris et triplets de cache étiquetés.
Méthode
Comparer le plan préalable lié à la configuration à une matrice complète de GET synthétiques par route et rôle. Détecter les marqueurs dans les en-têtes et corps, préserver les contradictions avant validation des doublons/lacunes, vérifier les redirections de même origine et les séquences froid/autorisé/rejeu.
Critères attendus
Pass couvre uniquement la matrice synthétique complète fournie : aucune réponse non autorisée ne contient de canari, les refus sont établis selon le plan, et chaque triplet froid → amorçage autorisé → rejeu anonyme est complet et ordonné. Une fuite attribuable ou une représentation 2xx non autorisée donne fail.
Quand le résultat reste indéterminé
Plan absent/futur/incohérent, cellule manquante ou dupliquée, en-tête d’identification absent/ambigu, redirection externe, 206, 304 sans représentation conservée, codage non pris en charge ou triplet/attribution incomplets.
Non-applicabilité
Aucune exemption atomique. Le NA du contrôle entier exige une revue d’inventaire complète, datée et motivée ; elle doit être liée à intent.
Hypothèses
Les fixtures sont fournies, synthétiques et non authentifiées. L’étiquette de rôle et l’identifiant de cache ne prouvent ni identité ni cache partagé.
Limites
Pas de DNS, socket, collecte live, identité réelle, authentification, cookie, cache réel, TLS, JavaScript, alias de chemin, HEAD ni évaluation de site entier. La détection de canaris couvre uniquement les codages implémentés ; le reste est inconclusif.
Version des règles 0.2.0-rc.1 · Fiche du protocole public · Source versionnée
Passer à la pratique
Une URL privée et les rôles autorisés.