De Same-Origin Policy is een cruciaal browserbeveiligingsmechanisme dat beperkt hoe een document of script geladen vanuit één origin kan interageren met bronnen van andere origins. Het helpt te voorkomen dat kwaadaardige sites gevoelige gegevens van andere websites lezen. Het beleid beschouwt twee URL's als dezelfde origin als ze hetzelfde protocol, host en poortnummer delen.
De same-origin policy (SOP) is de fundamentele isolatieregel van de browser. Twee URL's worden alleen als dezelfde origin beschouwd wanneer ze hetzelfde scheme, dezelfde host en dezelfde poort delen, dus https://shop.example:443 en http://shop.example of https://api.example zijn verschillende origins. Onder SOP mag een script dat op één origin draait sommige cross-origin bronnen laden (afbeeldingen, scripts, stijlen), maar kan het de responses niet lezen, de DOM van een andere origin niet inspecteren en niet bij de cookies, localStorage en IndexedDB komen. Het beleid wordt afgedwongen door de browser zelf, niet door de server, en het geldt per origin in plaats van per pagina. Zonder deze regel zou elk tabblad dat je opent stilletjes je webmail- of banksessie in een ander tabblad kunnen uitlezen.
SOP is wat een kwaadaardige site tegenhoudt om je ingelogde sessies elders te scripten. Omdat browsers je cookies automatisch aan verzoeken toevoegen, zou een pagina anders een fetch naar je bank kunnen doen en het saldo uit de response kunnen lezen. SOP blokkeert dat lezen, en daarom worden cross-site request forgery en cross-origin datadiefstal beperkt. Het is niet absoluut: het regelt lezen, niet verzenden, dus statuswijzigende verzoeken kunnen nog steeds afgaan, en verkeerd geconfigureerde CORS, te ruime postMessage-handlers of XSS die binnen de vertrouwde origin draait omzeilen het allemaal. SOP is een grens tussen origins, geen verdediging tegen code die al binnen je eigen origin wordt uitgevoerd.
Behandel SOP als een standaard die je wilt behouden, niet als een obstakel om omheen te werken. Wanneer je echt cross-origin toegang nodig hebt, gebruik dan CORS met een strakke allowlist in plaats van willekeurige origins te weerspiegelen of endpoints met credentials van een wildcard te voorzien. Valideer de origin van elke postMessage-gebeurtenis voordat je erop reageert, scope cookies zorgvuldig en houd authenticatietokens uit localStorage, waar elk same-origin script ze kan lezen. De lastigste opening om te dichten is een script dat binnen je eigen origin draait, aangezien SOP het volledig vertrouwt. Monitoren wat je third-party scripts tijdens runtime daadwerkelijk doen, de kern van client-side beveiliging, is hoe je misbruik van dat overgeërfde vertrouwen betrapt.
Nee. SOP beperkt het lezen van cross-origin responses, niet het versturen van de verzoeken. Een pagina kan nog steeds een verzoek naar een andere origin sturen, en de browser voegt je cookies toe. SOP voorkomt alleen dat de verzendende pagina leest wat terugkomt, en daarom blijven CSRF-verdedigingen zoals SameSite-cookies en tokens nodig.
Nee. app.example.com en api.example.com zijn verschillende origins omdat de host verschilt, dus SOP isoleert ze standaard. Verwante sites kunnen sommige interacties versoepelen via CORS-headers of, in beperkte legacy-gevallen, document.domain, maar browsers beperken die achterdeurtjes steeds meer ten gunste van expliciete CORS.
We answer client-side security questions every day. Bring yours.