La Same-Origin Policy (SOP) è il principio di sicurezza fondamentale dei browser web: una pagina può leggere e manipolare risorse (DOM, cookie, localStorage, risposta di una richiesta HTTP) soltanto se provengono dalla stessa origine della pagina stessa. È la barriera che impedisce a un sito malevolo di leggere i dati del tuo servizio bancario aperto in un’altra scheda.
Definizione di “stessa origine”
Due URL hanno la stessa origine se e solo se condividono schema, host e porta:
| URL | Stessa origine di https://esempio.it/pagina | Motivo |
|---|---|---|
https://esempio.it/altro | Sì | Schema, host, porta identici |
http://esempio.it/pagina | No | Schema diverso (http vs https) |
https://sub.esempio.it/pagina | No | Host diverso (sottodominio) |
https://esempio.it:8080/pagina | No | Porta diversa |
https://altro.it/pagina | No | Host diverso |
La porta 80 per HTTP e 443 per HTTPS sono implicite; https://esempio.it ed https://esempio.it:443 hanno la stessa origine.
Cosa viene bloccato
La SOP si applica in modo differenziato a seconda della risorsa:
Bloccato per default:
- Lettura della risposta di una richiesta XMLHttpRequest/Fetch verso un’origine diversa.
- Accesso al DOM di un
<iframe>con origine diversa (es. leggere il contenuto del frame). - Lettura di cookie, localStorage e sessionStorage di un’altra origine.
Non bloccato (incorporazione consentita, lettura no):
- Caricamento di immagini (
<img src="...">) da origini diverse — la pagina può mostrarle ma non leggerne i pixel via Canvas senza permesso. - Caricamento di script (
<script src="...">) — vengono eseguiti ma non si può leggere il loro sorgente. - Caricamento di CSS, font, video, audio da origini diverse.
- Invio di form (
<form action="...">) verso origini diverse — la SOP non blocca l’invio, solo la lettura della risposta.
Questo spiega perché CSRF è possibile nonostante la SOP: il form viene inviato, ma l’attaccante non può leggere la risposta.
Perché è fondamentale
Senza la SOP, un sito malevolo potrebbe, tramite JavaScript, fare richieste a https://banca.it/conti con i cookie dell’utente già autenticato e leggere il risultato — espropriando dati sensibili silenziosamente. La SOP impedisce questa lettura.
Eccezioni e meccanismi di relaxing
La SOP è talvolta troppo restrittiva per usi legittimi. I meccanismi ufficiali per rilassarla in modo controllato sono:
- CORS (Cross-Origin Resource Sharing) — il server dichiara esplicitamente quali origini possono leggere le sue risposte. È il meccanismo principale e quello descritto nella voce dedicata.
document.domain— deprecato. Permetteva a due sottodomini dello stesso dominio di condividere il DOM impostando lo stessodocument.domain. I browser moderni lo disabilitano per default.window.postMessage()— consente la comunicazione tra frame/finestre di origini diverse in modo esplicito e controllato, senza violare la SOP.- JSONP (JSON with Padding) — tecnica legacy che sfrutta il fatto che
<script src>non è bloccato dalla SOP. Oggi deprecata in favore di CORS.
Relazione con gli attacchi web
La SOP mitiga ma non elimina tutte le classi di attacco cross-origin:
- XSS: se l’attaccante riesce a iniettare script nella stessa origine della vittima, la SOP non protegge perché l’attacco è same-origin.
- CSRF: la SOP blocca la lettura della risposta ma non l’invio della richiesta — CSRF sfrutta esattamente questo.
- Clickjacking: la SOP non impedisce di incorporare una pagina in un iframe (a meno di
frame-ancestorsnella CSP oX-Frame-Options).
Contesto storico
La Same-Origin Policy fu introdotta da Netscape Navigator 2 nel 1995, originariamente per i cookie. Fu poi estesa a JavaScript e al DOM. È rimasta sostanzialmente invariata per trent’anni ed è oggi il fondamento su cui si appoggiano tutte le altre politiche di sicurezza del web.