---
title: Reguła tego samego pochodzenia (Same-origin policy)
slug: Web/Security/Same-origin_policy
tags:
  - Bezpieczeństwo
  - CORS
  - Host
  - JavaScript
  - Same-origin policy
  - URL
  - origin
  - pochodzenie
  - reguła tego samego pochodzenia
  - źródło
translation_of: Web/Security/Same-origin_policy
original_slug: Web/Bezpieczeństwo/Same-origin_policy
---
<p><span class="seoSummary"><strong>Same-origin policy</strong> (reguła tego samego pochodzenia) to istotny mechanizm bezpieczeństwa, który określa sposób, w jaki dokument lub skrypt jednego pochodzenia ({{Glossary("origin")}}) może komunikować się z zasobem innego pochodzenia.</span> Pozwala to na odizolowanie potencjalnie szkodliwych dokumentów i tym samym redukowane są czynniki sprzyjające atakom.</p>

<h2 id="Definicja_origin">Definicja "origin"</h2>

<p>Dwa URLe są <em>tego samego pochodzenia</em>, jeśli {{Glossary("protocol")}}, {{Glossary("port")}} (jeśli wyszczególniony) oraz {{Glossary("host")}} są takie same dla obu. Tego typu charakterystykę nazywa się "krotką schematu/hosta/portu" ("scheme/host/port tuple") lub po prostu "krotką" ("Krotka" to kolekcja elementów tworzących zbiór - generyczna forma, która może być podwójna/potrójna/poczwórna itd.).</p>

<p>Poniższa tabela zawiera przykłady zestawień "originów" z URLem <code>http://store.company.com/dir/page.html</code>:</p>

<table class="standard-table">
 <tbody>
  <tr>
   <th>URL</th>
   <th>Wynik</th>
   <th>Powód</th>
  </tr>
  <tr>
   <td><code>http://store.company.com/dir2/other.html</code></td>
   <td>Same origin</td>
   <td>Różni się tylko ścieżka</td>
  </tr>
  <tr>
   <td><code>http://store.company.com/dir/inner/another.html</code></td>
   <td>Same origin</td>
   <td>Różni się tylko ścieżka</td>
  </tr>
  <tr>
   <td><code>https://store.company.com/page.html</code></td>
   <td>Niepowodzenie</td>
   <td>Inny protokół</td>
  </tr>
  <tr>
   <td><code>http://store.company.com:81/dir/page.html</code></td>
   <td>Niepowodzenie</td>
   <td>Inny port (<code>http://</code> domyślnie jest portem 80)</td>
  </tr>
  <tr>
   <td><code>http://news.company.com/dir/page.html</code></td>
   <td>Niepowodzenie</td>
   <td>Inny host</td>
  </tr>
 </tbody>
</table>

<p>Zobacz również <a href="/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs">definicję "origin" dla URLów <code>file:</code></a>, ich zestawienie jest bardziej złożone.</p>

<h3 id="Odziedziczone_origin">Odziedziczone "origin"</h3>

<p>Skrypty wywoływane przez strony z URLami <code>about:blank</code> lub <code>javascript:</code> dziedziczą "origin" dokumentu zawierającego ten URL, ponieważ tego typu URLe nie zawierają informacji o serwerze źródłowym.</p>

<div class="note">
<p>Przykładowo, <code>about:blank</code> jest często używany jako URL nowego, pustego, wyskakującego okienka, w którym skrypt-rodzic umieszcza treść (np. przez mechanizm {{domxref("Window.open()")}}). Jeśli dane okienko zawiera również JavaScript, skrypt odziedziczy ten sam "origin" jak skrypt, który je utworzył.</p>
</div>

<div class="warning">
<p><code>data:</code> URLe zyskują nowy, pusty kontekst bezpieczeństwa.</p>
</div>

<h3 id="Wyjątki_w_Internet_Explorer">Wyjątki w Internet Explorer</h3>

<p>W Internecie Explorerze istnieją dwa wyjątki od reguły same-origin:</p>

<dl>
 <dt>Strefy Zaufania</dt>
 <dd>Jeśli obie domeny znajdują się w <em>strefie wysokiego zaufania</em> (np. firmowe domeny intranetu), wówczas ograniczenia same-origin nie są stosowane.</dd>
 <dt>Port</dt>
 <dd>IE nie bierze pod uwagę portów w trakcie sprawdzania obecności tego samego pochodzenia. Przykładowo, <code>https://company.com:81/index.html</code> i <code>https://company.com/index.html</code> są uznawane za posiadające ten sam "origin", więc nie są implementowane żadne ograniczenia .</dd>
</dl>

<p>Wspomniane wyjątki są niestandardowe i nie są wspierane przez inne przeglądarki.</p>

<h2 id="Zmiana_origin">Zmiana origin</h2>

<p>Strona może zmieniać swoje pochodzenie przy zachowaniu pewnych ograniczeń. Skrypt może nadać wartość {{domxref("document.domain")}} równą swojej obecnej domenie lub superdomenie swojej obecnej domeny. Jeśli odwołuje się do superdomeny obecnej domeny, wówczas krótsza superdomena jest brana pod uwagę przy kontroli same-origin.</p>

<p>Załóżmy, że skrypt z dokumentu pod adresem <code>http://store.company.com/dir/other.html</code> wywołuje poniższą linijkę:</p>

<pre class="brush: js">document.domain = "company.com";
</pre>

<p>Następnie strona może przejść pomyślnie kontrolę same-origin mając adres <code>http://company.com/dir/page.html</code> (przyjmując, że <code>http://company.com/dir/page.html</code> ma <code>document.domain</code> równe "<code>company.com</code>" by wskazać, że chce na to zezwalać - sprawdź: {{domxref("document.domain")}}). Jednakże, <code>company.com</code> <strong>nie może </strong>ustawić <code>document.domain</code> na <code>othercompany.com</code>, ponieważ nie jest to superdomena <code>company.com</code>.</p>

<p>Numer portu jest sprawdzany oddzielnie przez przeglądarkę. Każde odwołanie do <code>document.domain</code>, w tym <code>document.domain = document.domain</code>, spowoduje przypisanie numerowi portu wartości <code>null</code>. Jednakże, <strong>nie uda się</strong> nawiązać komunikacji <code>company.com:8080</code> z <code>company.com</code> tylko poprzez umieszczenie <code>document.domain = "company.com"</code> w pierwszym z nich. Taki zapis musi znajdować się w obu dokumentach, aby ich porty były równocześnie równe <code>null</code>.</p>

<div class="note">
<p><strong>Zauważ:</strong> Używając <code>document.domain</code> , żeby pozwolić subdomenie na bezpieczny dostęp do rodzica potrzebujesz ustawić <code>document.domain</code> na tę <em>samą wartość</em> jednocześnie w domenie rodzica i w subdomenie. Jest to wymagane nawet podczas zwykłego przywracania domeny rodzica do pierwotnej wartości. Niepowodzenie może skutkować błędami dostępu.</p>
</div>

<h2 id="Dostęp_sieciowy_cross-origin_międzyźródłowy">Dostęp sieciowy cross-origin (międzyźródłowy)</h2>

<p>Reguła tego samego pochodzenia kontroluje interakcje pomiędzy dwoma różnymi "originami", np. kiedy używasz elementu {{domxref("XMLHttpRequest")}} czy {{htmlelement("img")}}. Tego typu interakcje przeważnie dzielą się na trzy kategorie:</p>

<ul>
 <li><em>zapisy </em>cross-origin przeważnie są dopuszczane. Przykłady to: linki, przekierowania i wypełnienia formularzy. Niektóre zapytania HTTP wymagają <a href="/en-US/docs/Web/HTTP/CORS#Preflighted_requests">preflight</a>u.</li>
 <li><em>osadzanie </em>cross-origin jest przeważnie dopuszczane. (przykłady zostały wylistowane poniżej)</li>
 <li><em>odczyty </em>cross-origin przeważnie nie są dopuszczane, ale dostęp do odczytu jest zwykle możliwy przez osadzanie. Przykładowo, możliwy jest odczyt wymiarów osadzonego obrazka, działanie osadzonego skryptu czy <a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=629094">dostępność osadzonego źródła</a>.</li>
</ul>

<p>Poniżej znajdują się przykłady zasobów, które można osadzać międzyźródłowo:</p>

<ul>
 <li>JavaScript z <code>&lt;script src="…"&gt;&lt;/script&gt;</code>. Szczegóły dot. błędu dla błędów składniowych są dostępne wyłącznie dla skryptów same-origin.</li>
 <li>CSS podpinany poprzez <code>&lt;link rel="stylesheet" href="…"&gt;</code>. Zgodnie z <a class="external" href="http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html">luźniejszymi zasadami składni</a> CSS, cross-originowy CSS wymaga poprawnego nagłówka <code>Content-Type</code>. Ograniczenia różnią się w zależności od przeglądarki: <a class="external" href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/gg622939(v=vs.85)?redirectedfrom=MSDN">IE</a>, <a class="external" href="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html">Firefox</a>, <a class="external" href="https://bugs.chromium.org/p/chromium/issues/detail?id=9877">Chrome</a>, <a class="external" href="http://support.apple.com/kb/HT4070">Safari</a> (przewiń do CVE-2010-0051) i <a class="external" href="https://security.opera.com/cross-domain-data-theft-with-css-load-opera-security-advisories/">Opera</a>.</li>
 <li>Obrazki wyświetlane poprzez {{htmlelement("img")}}.</li>
 <li>Media odtwarzane poprzez {{htmlelement("video")}} i {{htmlelement("audio")}}.</li>
 <li>Wtyczki osadzane za pomocą {{htmlelement("object")}}, {{htmlelement("embed")}} oraz {{htmlelement("applet")}}.</li>
 <li>Czcionki używane poprzez {{cssxref("@font-face")}}. Niektóre przeglądarki zezwalają na czcionki cross-origin, inne wymagają same-origin.</li>
 <li>Cokolwiek osadzane poprzez {{htmlelement("frame")}} i {{htmlelement("iframe")}}. Strony mogą używać nagłówka {{HTTPHeader("X-Frame-Options")}}, by zapobiegać framingowi cross-origin.</li>
</ul>

<h3 id="Jak_umożliwić_dostęp_cross-origin">Jak umożliwić dostęp cross-origin</h3>

<p>Poprzez <a href="/en-US/docs/Web/HTTP/CORS">CORS</a> można zezwolić na dostęp cross-origin. CORS jest częścią {{Glossary("HTTP")}}, co pozwala serwerom na określanie, które hosty są upoważnione do ładowania treści z tego serweru.</p>

<h3 id="Jak_zablokować_dostęp_cross-origin">Jak zablokować dostęp cross-origin</h3>

<ul>
 <li>By uniemożliwić zapisy cross-origin należy sprawdzić token w żądaniu — chodzi konkretniej o token <a class="external" href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">Cross-Site Request Forgery (CSRF)</a>. Odczyty typu cross-origin muszą być zablokowane na stronach używających tego typu tokenu.</li>
 <li>By uniemożliwić odczyty cross-origin należy upewnić się, że dane zasoby nie są osadzalne. Często koniecznym jest uniemożliwienie osadzania, ponieważ osadzanie źródła zawsze ujawnia jakieś informacje o nim.</li>
 <li>By uniemożliwić osadzanie cross-origin należy upewnić się, że dane zasoby nie mogą być interpretowane jako jeden z osadzanych formatów wylistowanych poniżej. Przeglądarki mogą ignorować nagłówki <code>Content-Type</code>. Przykładowo, jeśli w dokumencie HTML umieszczony zostanie tag <code>&lt;script&gt;</code>, przeglądarka będzie próbować parsować HTML jako JavaScript. Jeśli zasób nie jest głównym podprogramem strony do zapobiegania osadzaniu można dodatkowo użyć tokenu CSRF.</li>
</ul>

<h2 id="Dostęp_cross-origin_API_skryptu">Dostęp cross-origin API skryptu</h2>

<p>API JavaScriptu, jak {{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}} i {{domxref("window.opener")}} pozwalają dokumentom na bezpośrednią, wzajemną referencję. Jeśli dwa dokumenty nie są tego samego pochodzenia, referencje te umożliwiają bardzo ograniczony dostęp do obiektów {{domxref("Window")}} i {{domxref("Location")}}, jako opisano w następnych dwóch sekcjach.</p>

<p>Do komunikacji pomiędzy dokumentami o różnym pochodzeniu stosuje się {{domxref("window.postMessage")}}.</p>

<p>Specyfikacja: <a class="external" href="https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects">Standard HTML § Obiekty cross-origin</a>.</p>

<h3 id="Window">Window</h3>

<p>Poniższy dostęp cross-origin jest dopuszczany w przypadku wymienionych właściwości <code>Window</code>:</p>

<table class="fullwidth-table standard-table">
 <thead>
  <tr>
   <th scope="col">Metody</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>{{domxref("window.blur")}}</td>
  </tr>
  <tr>
   <td>{{domxref("window.close")}}</td>
  </tr>
  <tr>
   <td>{{domxref("window.focus")}}</td>
  </tr>
  <tr>
   <td>{{domxref("window.postMessage")}}</td>
  </tr>
 </tbody>
</table>

<table class="fullwidth-table standard-table">
 <thead>
  <tr>
   <th scope="col">Własności</th>
   <th scope="col"></th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>{{domxref("window.closed")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.frames")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.length")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.location")}}</td>
   <td>Odczyt/Zapis.</td>
  </tr>
  <tr>
   <td>{{domxref("window.opener")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.parent")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.self")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.top")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
  <tr>
   <td>{{domxref("window.window")}}</td>
   <td>Tylko do odczytu.</td>
  </tr>
 </tbody>
</table>

<p>Niektóre przeglądarki zezwalają na dostęp większej ilości właściwości, niż wypisane powyżej.</p>

<h3 id="Location">Location</h3>

<p>Poniższy dostęp cross-origin jest dopuszczany w przypadku właściwości <code>Location</code>:</p>

<table class="fullwidth-table standard-table">
 <thead>
  <tr>
   <th scope="col">Metody</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>{{domxref("location.replace")}}</td>
  </tr>
 </tbody>
</table>

<table class="fullwidth-table standard-table">
 <thead>
  <tr>
   <th scope="col">Atrybuty</th>
   <th scope="col"></th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>{{domxref("URLUtils.href")}}</td>
   <td>Tylko do zapisu.</td>
  </tr>
 </tbody>
</table>

<p>Niektóre przeglądarki umożliwiają dostęp do większej liczby właściwości, niż wymienione powyżej.</p>

<h2 id="Dostęp_cross-origin_do_danych_pamięci">Dostęp cross-origin do danych pamięci</h2>

<p>Dostęp do danych przechowywanych w przeglądarce, jak <a href="/en-US/docs/Web/API/Web_Storage_API">localStorage</a> czy <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a> są odseparowane pochodzeniem. Każdy origin otrzymuje własną, odseparowaną pamięć i JavaScript jednego pochodzenia nie może odczytywać lub wpisywać niczego do pamięci należącej do innego originu.</p>

<p>Ciasteczka (cookies) używają oddzielnej definicji originów. Strona może ustalić ciasteczko dla własnej domeny lub domeny-rodzica dopóki, gdy domena-rodzic nie jest sufiksem publicznym. Firefox i Chrome używają listy sufiksów publicznych (<a class="external" href="https://publicsuffix.org/">Public Suffix List</a>), by zweryfikować czy domena jest sufiksem publicznym. Internet Explorer używa własnej, wewnątrznej metody weryfikacji czy domena jest sufiksem publicznym. Przeglądarka udostępni ciasteczko podanej domenie zawierającej jakiekolwiek subdomeny, niezależnie jaki protokół (HTTP/HTTPS) czy port jest używany. Przy ustalaniu ciasteczka możliwe jest określenie limitu dostępności używając flag domeny (Domain), ścieżki (Path), bezpiecznej (Secure) i Http-Only. Gdy odczytywane jest ciasteczko nie można zobaczyć, gdzie zostało ustalone. Nawet jeśli używane są wyłącznie bezpieczne połączenia https dane ciasteczko mogło zostać ustalone poprzez połączenie niebezpieczne.</p>

<h2 id="Zobacz_również">Zobacz również</h2>

<ul>
 <li><a href="/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs">Reguła same-origin dla file: URIy</a></li>
 <li><a href="http://www.w3.org/Security/wiki/Same_Origin_Policy">Reguła Same-Origin na W3C</a></li>
 <li><a href="https://web.dev/secure/same-origin-policy">https://web.dev/secure/same-origin-policy</a></li>
</ul>

<div class="originaldocinfo">
<h2 id="Original_Document_Information" name="Original_Document_Information">Informacje dot. dokumentu źródłowego</h2>

<ul>
 <li>Author(s): Jesse Ruderman</li>
</ul>
</div>

<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>