12. Same-origin policy : lecture et envoi

Comprendre le mécanisme

La politique de même origine borne plusieurs accès entre documents ou ressources d’origines différentes. Elle protège notamment certaines lectures et interactions, mais n’interdit pas uniformément tout envoi interorigine. Une image distante, une navigation ou un formulaire peuvent encore produire du trafic dans les conditions prévues par le navigateur. Ce modèle explique pourquoi l’absence d’une permission de lecture CORS ne prouve pas qu’une action serveur n’a pas été déclenchée.

Raisonner et vérifier

Construisez votre modèle de menace avec deux questions distinctes : la demande part-elle, et le script peut-il exploiter la réponse ? Un serveur doit autoriser les mutations même si la page appelante ne pourra pas lire leur résultat. Les mécanismes CSRF, l’authentification et la politique de cookies complètent cette frontière. Testez avec deux origines de laboratoire plutôt qu’une page unique.

Frontière de lecture

La SOP limite certains accès entre origines. Lecture et émission de requête ont des règles distinctes. La SOP limite certains accès entre origines depuis le navigateur. Elle ne constitue pas une authentification du client ni une interdiction universelle pour les demandes qui atteignent le serveur.

Ressource intégrée

Une image externe peut être demandée sans lecture libre du contenu. Chargement et exposition au script ne sont pas équivalents. Une image externe peut être chargée sans donner au script une lecture libre de son contenu. Distinguez déclenchement réseau, affichage et accès programmatique aux données de la réponse.

Formulaire externe

Un formulaire peut déclencher une requête inter-origines. Le serveur doit protéger les mutations pertinentes. Un formulaire hébergé ailleurs peut envoyer une demande vers votre service selon les règles navigateur. Si une identité est jointe, l’effet doit être contrôlé même lorsque la réponse reste illisible au site initiateur.

Partage CORS

CORS peut autoriser certaines lectures contrôlées. L’autorisation porte sur un contrat précis de partage. CORS peut autoriser certaines lectures que la politique d’origine limiterait autrement. Cette permission est évaluée par le navigateur et ne remplace pas les contrôles serveur sur acteur et ressource.

Client serveur

Un client serveur n’est pas régi comme un script navigateur par la SOP. Les clients directs demandent des contrôles serveur. Un script curl ou un backend peut contacter l’API sans appliquer la SOP du navigateur. Protégez donc les données par une authentification et des règles d’accès réelles côté serveur.

Contrôle API

L’authentification doit être vérifiée côté API. Une politique de lecture n’établit pas l’identité. L’API doit vérifier credentials et droits sur chaque opération sensible. Le fait qu’un frontend soit déployé sur une origine connue ne rend pas toutes les demandes reçues authentiques ou autorisées.

Frames

Les frames conservent des frontières d’accès. L’intégration ne fusionne pas automatiquement les origines. Un document intégré depuis une autre origine conserve des restrictions d’accès. N’en déduisez pas qu’il ne peut pas afficher une interface trompeuse ; le framing et le clickjacking demandent aussi une politique.

XSS locale

Une XSS de même origine peut agir dans le contexte de la page. Le script hostile peut bénéficier du contexte compromis. Une XSS s’exécute dans le contexte de l’origine compromise et peut agir avec ses capacités. La SOP ne protège pas cette page contre un code hostile déjà exécuté dans son propre périmètre.

Mesures séparées

Les tests doivent distinguer réponse envoyée et réponse lisible. Le navigateur peut masquer une réponse déjà produite. Dans un laboratoire, observez le journal serveur puis la tentative de lecture JavaScript. Une erreur CORS dans la console peut coexister avec une demande reçue et un effet déjà produit.

Autorisation objet

La permission sur l’objet reste une règle serveur. Le modèle du navigateur ne connaît pas ces règles métier. Même une lecture techniquement autorisée entre origines doit respecter les droits de l’acteur. Essayez un identifiant appartenant à un autre compte et vérifiez le refus sans fuite de contenu.

Atelier guidé : lire, expliquer et vérifier le code

<form method="post" action="https://booking.example.test/lab/cancel">
  <input name="reservation" value="42">
</form>
<!-- Formulaire sur une autre origine ; le serveur doit appliquer ses contrôles. -->

Le formulaire cross-origin peut provoquer une demande sans offrir au site tiers la lecture de sa réponse. Il faut donc protéger l’annulation avant son effet, avec les contrôles adaptés au contexte de session. Testez séparément réception de la demande, décision serveur et visibilité de la réponse.

Le serveur doit vérifier sa défense CSRF. Un effet doit être protégé même si la réponse reste illisible au script tiers. La SOP n’est pas une interdiction universelle d’émission. Les formulaires peuvent soumettre des données.

Travail pratique : Créez deux origines locales et comparez chargement d’image, navigation et lecture par fetch. Sur B, utilisez un endpoint sans mutation.

Critères de correction : Relevez les requêtes reçues puis les accès possibles depuis le script. Classez les résultats par mécanisme et gardez les mutations derrière une politique serveur indépendante de l’accès à la réponse.