{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/same-origin-policy","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/same-origin-policy/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/same-origin-policy/"},"term":{"en":"Same-origin policy","da":"Same-origin policy"},"aka":{"en":["SOP"],"da":["SOP"]},"domain":["cs","security"],"cluster":"web","layer":"application","status":"current","era":1995,"summary":{"en":"A browser rule that stops a page from one site reading data that belongs to another site open in the same browser.","da":"En browserregel, der forhindrer en side fra ét site i at læse data, som tilhører et andet site åbent i samme browser."},"body":{"formal":{"en":"A rule built into every web browser that lets code on a page read content only from its own origin - the same protocol (such as https), host name and port in the URL; it may still send requests to other origins, but cannot read their replies unless they allow it.","da":"En regel, der er bygget ind i alle webbrowsere, og som kun lader kode på en side læse indhold fra sin egen oprindelse - samme protokol (fx https), værtsnavn og port i URL'en; koden må stadig sende forespørgsler til andre oprindelser, men kan ikke læse svarene, medmindre de tillader det."},"plain":{"en":"Like hotel rooms on one key card system - your card works for your own room, and you can knock on any door, but you cannot walk in and read what lies on the next guest's desk.","da":"Som hotelværelser med nøglekort - dit kort virker til dit eget værelse, og du kan banke på alle døre, men du kan ikke gå ind og læse, hvad der ligger på næste gæsts skrivebord."},"inPractice":{"en":"A case officer has the municipality's web-based email open in one tab and a shady game site in another; the game's code can send a request to the email site, but the browser will not let it read the inbox that comes back.","da":"En sagsbehandler har kommunens webmail åben i én fane og et lyssky spilsite i en anden; spillets kode kan sende en forespørgsel til webmailen, men browseren lader den ikke læse den indbakke, der kommer tilbage."},"whyItMatters":{"en":"Without it any page could read everything a user sees on every other site; but it does not stop requests from being sent, which is why cross-site request forgery still works, and XSS gets around it by running inside the trusted site itself.","da":"Uden den kunne enhver side læse alt, hvad brugeren ser på alle andre sites; men den stopper ikke, at forespørgsler bliver sendt, og derfor virker CSRF stadig, mens XSS kommer uden om den ved at køre inde på selve det betroede site."}},"deepDive":{"en":"An origin is the tuple of scheme, host and port, as defined in RFC 6454 and in the WHATWG HTML and URL standards: https://a.example, http://a.example and https://a.example:8443 are three different origins, while two URLs differing only in path share one. Some documents get an opaque origin, for example sandboxed iframes and data: URLs; it serialises as the string \"null\" and is same-origin with nothing but itself. The policy arrived with JavaScript in Netscape Navigator 2.0 in 1995 and is really a family of rules applied to different APIs: script access to another window's DOM, reading responses from fetch or XMLHttpRequest, reading pixels from a canvas tainted by cross-origin images, and per-origin storage such as localStorage and IndexedDB, which browsers increasingly also partition by top-level site.\n\nThe asymmetry is the key design point. Cross-origin writes and embedding are allowed: a page may submit forms, follow links and embed images, scripts, stylesheets and frames from anywhere. Cross-origin reads are blocked. That is why JSONP worked, by embedding data as a script, and why cross-site script inclusion attacks against JSON endpoints existed. Controlled relaxation comes from CORS, specified in the WHATWG Fetch Standard: the server opts in with Access-Control-Allow-Origin; requests with non-simple methods or headers first trigger an OPTIONS preflight; and credentialed requests require an exact origin, not the wildcard, together with Access-Control-Allow-Credentials: true. Cross-window messaging uses postMessage, where the receiver must check event.origin. The old document.domain relaxation is deprecated and being removed from browsers.\n\nCORS misconfigurations are a recurring finding: reflecting any Origin header together with credentials, trusting the \"null\" origin (which sandboxed attacker pages can produce), or validating origins with a suffix or regex match that also accepts evil-example.com. Another subtlety is the difference between origin and site, where site means scheme plus registrable domain from the Public Suffix List. SameSite cookies and Chrome's site isolation work on sites, so app.example.com and forgotten.example.com are cross-origin but same-site, and an XSS on the forgotten subdomain can undermine SameSite as a CSRF defence.\n\nThe policy has clear limits. It does not stop requests being sent, so CSRF remains possible; it cannot help once attacker script runs inside the trusted origin, which is XSS; and Spectre (2018) showed that data sharing a process with attacker code can leak through timing side channels regardless of any policy. Browsers responded with process-per-site isolation and opaque-response blocking, and pages that need high-resolution timers or SharedArrayBuffer must be cross-origin isolated using COOP: same-origin together with COEP: require-corp. Content Security Policy is complementary: it limits what a page may load and execute, not what it may read.","da":"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.\n\nAsymmetrien 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.\n\nFejlkonfigureret 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.\n\nPolitikken 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."},"edges":[{"type":"requires","to":"cs/web-browser","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/url","confidence":"high","strength":"normal"}],"depth":6,"sources":[{"title":"MDN Web Docs - Same-origin policy","url":"https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy","tier":"official-doc","publisher":"Mozilla"},{"title":"RFC 6454 - The Web Origin Concept","url":"https://www.rfc-editor.org/rfc/rfc6454","tier":"standard","publisher":"IETF"}],"draft":true}