Same-origin policy

En oprindelse (origin) er tuplen af skema, vært og port, som defineret i RFC 6454 og i WHATWG's HTML- og URL-standarder: https://a.example, http://a.example og https://a.example:8443 er tre forskellige oprindelser, mens to URL'er, der kun adskiller sig i stien, deler én. Nogle dokumenter får en opak oprindelse, fx sandboxede iframes og data:-URL'er; den serialiseres som strengen "null" og er kun same-origin med sig selv. Politikken kom med JavaScript i Netscape Navigator 2.0 i 1995 og er i virkeligheden en familie af regler for forskellige API'er: scripts adgang til et andet vindues DOM, læsning af svar fra fetch eller XMLHttpRequest, læsning af pixels fra et canvas, der er "tainted" af billeder fra andre oprindelser, og lager pr. oprindelse som localStorage og IndexedDB, som browsere i stigende grad også partitionerer efter topniveau-site.

Asymmetrien er det centrale designprincip. Skrivning og indlejring på tværs af oprindelser er tilladt: en side må sende formularer, følge links og indlejre billeder, scripts, stylesheets og frames fra hvor som helst. Læsning på tværs er blokeret. Derfor virkede JSONP, der indlejrede data som et script, og derfor fandtes cross-site script inclusion-angreb mod JSON-endpoints. Kontrolleret lempelse sker via CORS, specificeret i WHATWG's Fetch Standard: serveren giver tilladelse med Access-Control-Allow-Origin; forespørgsler med ikke-simple metoder eller headere udløser først en OPTIONS-preflight; og forespørgsler med loginoplysninger kræver en præcis oprindelse, ikke wildcard, sammen med Access-Control-Allow-Credentials: true. Beskeder mellem vinduer bruger postMessage, hvor modtageren skal tjekke event.origin. Den gamle lempelse via document.domain er forældet og ved at blive fjernet fra browserne.

Fejlkonfigureret CORS er et tilbagevendende fund: at spejle enhver Origin-header sammen med loginoplysninger, at stole på oprindelsen "null" (som sandboxede angribersider kan frembringe) eller at validere oprindelser med et suffiks- eller regex-match, der også accepterer evil-example.com. En anden finesse er forskellen på oprindelse og site, hvor site betyder skema plus registrerbart domæne fra Public Suffix List. SameSite-cookies og Chromes site isolation arbejder med sites, så app.example.com og glemt.example.com er forskellige oprindelser, men samme site, og en XSS på det glemte underdomæne kan undergrave SameSite som forsvar mod CSRF.

Politikken har klare grænser. Den forhindrer ikke, at forespørgsler sendes, så CSRF er stadig mulig; den hjælper ikke, når angriberens script kører inde i den betroede oprindelse, dvs. XSS; og Spectre (2018) viste, at data, der deler proces med angriberkode, kan lække via tidsbaserede sidekanaler uanset politik. Browserne svarede med procesisolation pr. site og blokering af opake svar, og sider, der har brug for højopløselige timere eller SharedArrayBuffer, skal være cross-origin isolated med COOP: same-origin sammen med COEP: require-corp. Content Security Policy supplerer: den begrænser, hvad en side må indlæse og køre, ikke hvad den må læse.