initial commit

6 files changed, 663 insertions, 0 deletions

diff --git a/files/pl/web/bezpieczeństwo/certificate_transparency/index.html b/files/pl/web/bezpieczeństwo/certificate_transparency/index.html
new file mode 100644
index 0000000000..7a9b814c43
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/certificate_transparency/index.html
@@ -0,0 +1,63 @@
+---
+title: Certificate Transparency
+slug: Web/Bezpieczeństwo/Certificate_Transparency
+tags:
+  - Bezpieczeństwo
+  - Web
+  - bezpieczeństwo aplikacji WWW
+translation_of: Web/Security/Certificate_Transparency
+---
+<p><span class="seoSummary"><strong>Certyfikat Przejrzystości (Certificate Transparency)</strong></span> to otwarta platforma programistyczna (framework) stworzona do ochrony oraz monitorowania braków w certyfikacji. Świeżo wydane certyfikaty dostają się do obiegu publicznego, często niezależne logi CT zostają wpisane do rejestru, przez co zachowany zostaje zabezpieczony kryptograficznie rekord certyfikatów TLS.</p>
+
+<p>W ten sposób organy certyfikujące (CA) mogą podlegać znacznie większemu, publicznemu nadzorowi i kontroli. Potencjalnie szkodliwe certyfikaty, jak te, które naruszają <em>Podstawowe Wymogi </em>CA/B Forum mogą zostać znacznie sprawniej wykryte i cofnięte. Podmioty zajmujące się sprzedażą przeglądarek oraz opiekuni certyfikatów zaufanych są również uprawnieni do podejmowania gruntowniej popartych decyzji dot. problematycznych organów certyfikujących, którym mogą odmowić zaufania.</p>
+
+<h2 id="Kontekst">Kontekst</h2>
+
+<p>Logi CT są budowane w ramach struktury danych drzewa Merkla (Merkle tree). Węzły są oznaczane hashami kryptograficznymi ich węzłów potomnych. Liście (leaf nodes) zawierają hashe aktualnych części danych. Oznaczenie węzła głównego (root node) zależy jednakże od wszystkich pozostałych węzłów w drzewie.</p>
+
+<p>W kontekście przejrzystości certyfikacji dane hashowane przez liście są certyfikatami wydawanymi obecnie przez różne CA. Obecność certyfikatu może zostać zweryfikowana przez <em>dowód kontroli </em>skutecznie generowany i weryfikowany w czasie działania logarytmicznego - logarithmic O(log n) time.</p>
+
+<p>Pierwotnie, w 2013 roku przejrzystość certyfikacji służyła przeciwdziałaniu narażania CA (naruszenia DigiNotar w 2011 roku), wątpliwym decyzjom (incydent Trustwave subordinate root w 2012 roku) oraz technicznym problemom wydawniczym (emisja słabego, 512-bitowego certyfikatu przez Digicert Sdn Bhd w Malezji)</p>
+
+<h2 class="western" id="Wdrożenie">Wdrożenie</h2>
+
+<p>Gdy certyfikaty zostają dostarczone do rejestru CT, <em>znacznik SCT</em> (<em>signed certificate timestamp</em>) zostaje wygenerowany i zwrócony. Służy to jako dowód, że certyfikat został dostarczony i zostanie dodany do rejestru.</p>
+
+<p>Wg specyfikacji podczas komunikacji serwery zgodne muszą dostarczać numery tych SCTów do klientów TLS. Może do tego dojść na kilka różnych sposobów:</p>
+
+<ul>
+ <li>rozszerzenie certyfikatu X.509v3, które umieszczają znaczniki SCT bezpośrednio do certyfikatów liści</li>
+ <li>rozszerzenie TLS typu <code>signed_certificate_timestamp</code> wysyłane podczas uzgadniania (handshake)</li>
+ <li>"zszywanie" OCSP (rozszerzenie TLS <code>status_request</code>) i dostarczanie <code>SignedCertificateTimestampList</code> z jednym lub większą liczbą SCTsów</li>
+</ul>
+
+<p>Przy rozszerzeniu certyfikatu X.509 o włączonych SCTsach decydują organy certyfikujące. Przy stosowaniu tego typu mechanizmu nie powinna istnieć potrzeba modyfikacji serwerów webowych.</p>
+
+<p>W przypadku ostatnich metod serwery powinny być aktualizowane, aby móc wysyłać żądane dane. Korzyść stanowi fakt, że operator serwera może modyfikować źródła rejestru CT dostarczając SCTsy wysyłane przez rozszerzenie TLS/"zszytą" odpowiedź OCSP.</p>
+
+<h2 id="Wymagania_przeglądarki">Wymagania przeglądarki</h2>
+
+<p>Google Chrome wymaga umieszczania rejestru CT dla wszystkich kwestii związanych z emisjami certyfkatów z datą notBefore po 30 kwietnia 2018 roku. Użytkownicy zostaną uchronieni przed odwiedzaniem stron używających niezgodnych certyfikatów TLS. Wcześniej Chrome wymagało umieszczania <em>Rozszerzonej Walidacji</em> (EV) oraz certyfikatów wydawanych przez Symantec.</p>
+
+<p>Apple <a href="https://support.apple.com/en-gb/HT205280">wymaga</a> zróżnicowanej liczby SCTsów dla Safari i innych serwerów celem zaufania certyfikatom.</p>
+
+<p>Firefox aktualnie ani <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1281469">nie sprawdza</a> ani nie wymaga stosowania rejestru CT dla stron odwiedzanych przez użytkowników.</p>
+
+<p>Nagłówek <a href="/en-US/docs/Web/HTTP/Headers/Expect-CT">Expect-CT </a>może zostać użyty do żądania, by przeglądarka zawsze wymuszała wymóg przejrzystości certyfikacji (np. w Chrome nawet, jeśli certyfikat został wydany z datą notBefore, przed kwietniem)</p>
+
+<h2 id="Specyfikacje">Specyfikacje</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specyfikacja</th>
+   <th scope="col">Status</th>
+   <th scope="col">Komentarz</th>
+  </tr>
+  <tr>
+   <td><a class="external external-icon" href="https://tools.ietf.org/html/rfc6962" hreflang="en" lang="en" rel="noopener">Certificate Transparency</a></td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/pl/web/bezpieczeństwo/index.html b/files/pl/web/bezpieczeństwo/index.html
new file mode 100644
index 0000000000..0d3cdd2c07
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/index.html
@@ -0,0 +1,24 @@
+---
+title: Bezpieczeństwo aplikacji WWW
+slug: Web/Bezpieczeństwo
+tags:
+  - Bezpieczeństwo
+  - Web
+  - bezpieczeństwo aplikacji WWW
+translation_of: Web/Security
+---
+<div class="summary">
+<p>Zapewnienie bezpieczeństwa Twojej strony lub aplikacji WWW jest niezwykle istotne. Nawet proste błędy w kodzie mogą skutkować wyciekiem prywatnych danych i ich kradzieżą przez nieodpowiednie osoby. Wymienione tutaj artykuły dot. bezpieczeństwa aplikacji WWW dostarczą Ci informacji, które mogą okazać się pomocne w zabezpieczeniu Twojej strony i jej kodu przez atakami i kradzieżą danych.</p>
+</div>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<h2 id="Zobacz_również">Zobacz również</h2>
+
+<ul>
+ <li><a href="https://lists.mozilla.org/listinfo/dev-security">Mozilla mailing list</a></li>
+ <li><a href="https://blog.mozilla.com/security/">Blog</a></li>
+ <li><a href="https://twitter.com/mozsec">@mozsec on Twitter</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages}}</p>
diff --git a/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/index.html b/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/index.html
new file mode 100644
index 0000000000..93555b6a71
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/index.html
@@ -0,0 +1,36 @@
+---
+title: Podstawy bezpieczeństwa informacji
+slug: Web/Bezpieczeństwo/Podstawy_bezpieczenstwa_informacji
+tags:
+  - Bezpieczeństwo
+  - Początkujący
+  - bezpieczeństwo aplikacji WWW
+translation_of: Web/Security/Information_Security_Basics
+---
+<p>Podstawowa znajomość bezpieczeństwa informacji może pomóc Ci uniknąć pozostawiania Twojego oprogramowania i stron WWW niezabezpieczonych oraz zawierających podatności, które później mogą zostać wykorzystane do osiągnięcia korzyści finansowych lub do innych, podejrzanych celów. Te arykuły mogą Ci pomóc zdobyć potrzebną bazę wiedzy.Dzięki zapoznaniu się z nimi będziesz świadomy/a, jak ważne jest bezpieczeństwo podczas tworzenia stron WWW oraz podczas implementacji treści.</p>
+
+<dl>
+ <dt><a href="/en-US/Learn/Confidentiality,_Integrity,_and_Availability">Poufność, Integralność i Dostępność</a></dt>
+ <dd>
+ <p>Opisuje najważniejsze cele bezpieczeństwa, które są absolutnie niezbędne do zrozumienia istoty bezpieczeństwa</p>
+ </dd>
+ <dt><a href="/en-US/Learn/Vulnerabilities">Podatności</a></dt>
+ <dd>Definiuje główne kategorie podatności i omawia obecność podatności w każdym oprogramowaniu</dd>
+ <dt><a href="/en-US/Learn/Threats">Zagrożenia</a></dt>
+ <dd>Krótko przedstawia główne zagrożenia</dd>
+ <dt><a href="/en-US/Learn/Security_Controls">Kontrole Bezpieczeństwa</a></dt>
+ <dd>Definiuje główne kategorie kontroli bezpieczeństwa i omawia ich potencjalne wady</dd>
+ <dt><a href="/en-US/Learn/TCP_IP_Security">Bezpieczeństwo TCP/IP</a></dt>
+ <dd>Zarys modelu TCP/IP z naciskiem na aspekty bezpieczeństwa SSL</dd>
+</dl>
+
+<h2 id="Zobacz_również">Zobacz również</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Mozilla/Security">Bezpieczeństwo przeglądarek</a></li>
+ <li><a href="/en-US/docs/Web/Security">Bezpieczeństwo webowe</a></li>
+ <li><a href="/en-US/docs/Web/Security/Securing_your_site">Zabezpieczanie Twojej strony WWW</a></li>
+ <li><a href="/en-US/docs/Security/Firefox_Security_Basics_For_Developers">Podstawy Bezpieczeństwa Firefoxa dla Developerów</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/podatnosci/index.html b/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/podatnosci/index.html
new file mode 100644
index 0000000000..772145243a
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/podstawy_bezpieczenstwa_informacji/podatnosci/index.html
@@ -0,0 +1,100 @@
+---
+title: Podatności
+slug: Web/Bezpieczeństwo/Podstawy_bezpieczenstwa_informacji/Podatnosci
+tags:
+  - Bezpieczeństwo
+  - Początkujący
+  - Tutorial
+  - bezpieczeństwo aplikacji WWW
+  - podatności
+  - samouczek
+translation_of: Archive/Security/Vulnerabilities
+---
+<div class="summary">
+<p>Niniejszy artykuł tłumaczy czym są podatności i omawia ich występowanie we wszystkich systemach.</p>
+
+<p>Podatność to słabość systemu, która może zostać wykorzystana do naruszenia poufności, integralności i/lub dostępności. Podatności można kategoryzować na wiele sposobów. W tym artykule użyjemy trzech kategorii najwyższego ryzyka: usterki oprogramowania, problemy przy konfiguracji zabezpieczeń i nadużycie funkcji oprogramowania. Kategorie te zostały umówione poniżej.</p>
+</div>
+
+<h2 id="Kategorie_podatności">Kategorie podatności</h2>
+
+<p><em>Usterki oprogramowania</em> są wynikiem niezamierzonego błędu w architekturze lub samym kodzie oprogramowania. Jako przykład może posłużyć błąd przy weryfikacji wprowadzanych danych, np. kiedy dane wprowadzane przez użytkownika nie są prawidłowo sprawdzane pod kątem prób wprowadzania szkodliwych stringów używających nieporządanych znaków czy zbyt długich wartości wiązanych ze znanymi atakami. Inny przykład to błąd dopuszczający sytuację wyścigu ("race condition"), przez który atakujący może przeprowadzić określone działanie posiadając podniesione uprawnienia.</p>
+
+<p>Ustawienia konfiguracji bezpieczeństwa to element bezpieczeństwa oprogramowania który może zostać zmieniony przez samo oprogramowanie. Przykłady ustawień to np. system operacyjny oferujący dostęp do listy kontrolnej przydzielającej prawa użytkowników do odczytu i modyfikacji plików oraz np. aplikacja dopuszczająca umożliwianie lub uniemożliwianie szyfrowania danych wrażlliwych znajdujących się w aplikacji.</p>
+
+<p><em>Problemy przy konfiguracji zabezpieczeń </em>to m.in. używanie ustawień konfiguracji bezpieczeństwa w sposób, który ma negatywny wpływ na bezpieczeństwo oprogramowania.</p>
+
+<p>Cecha oprogamowania to możliwość funkcyjna udostępniona przez oprogramowanie. <em>Podatność na nadużycie funkcji oprogramowania</em> to taki typ podatności, w której dana funkcja stanowi dziurę bezpieczeństwa systemu. Tego typu podatności stwarza projektant oprogramowania, gdy aby uzyskać dodatkowe funkcje oprogramowania zakłada idylliczny scenariusz i ryzykuje tym samym podatność na ewentualne ataki.</p>
+
+<p>Na przykład, oprogramowanie klienckie email może zawierać funkcjonalność, która umożliwia wyrenderowanie treści HTML w wiadomościach email. Atakujący może w tej sytuacji stworzyć fałszywy mail zawierający hiperlink, który po wyrenderowaniu w HTML wygląda na nieszkodliwy, a w rzeczywistości po kliknięciu przekierowuje odbiorcę na szkodliwą stronę. Jednym z idyllicznych założeń w fazie projektowania funkcji renderowania treści HTML była myśl, że użytkownicy nie otrzymają szkodliwych hiperlinków i nie będą w nie klikać.</p>
+
+<p>Podatności nadużycia funkcji oprogramowania pojawiają się podczas projektowania oprogramowania lub jego komponentów (np. protokół, który oprogramowanie wdraża). Idylliczne założenia mogą być oczywiste - np. projektant jest świadomy słabości bezpieczeństwa i zakłada, że oddzielna kontrola bezpieczeństwa wystarczy.</p>
+
+<p>Często jednak założenia idylliczne są dwuznaczne, chociażby utworzenie funkcji bez wcześniejszego ocenienia ryzyka. Dodatkowo zagrożenia mogą się zmieniać w czasie życia oprogramowania czy protokołu w nim użytego.</p>
+
+<p>Przykład? Address Resolution Protocol (ARP) zakłada, że odpowiedź ARP zawiera prawidłowe mapowanie pomiędzy adresami Media Access Control (MAC) a Internet Protocol (IP). Cache ARP używają tej informacji, by umożliwić przydatne działanie - zezwolenie na wysyłanie danych pomiędzy urządzeniami w jednej sieci lokalnej. Jednakże atakujący mógłby wygenerować fałszywe komunikaty ARP celem zmylenia tabli systemowej ARP i w ten sposób przeporwadzić atak denial-of-service lub man-in-the-middle attack.</p>
+
+<p>Protokuł ARP został ustandaryzowany ponad 25 lat temu, a zagrożenia znacząco się od tego czasu zmieniły, więc założenia idylliczne, które były wówczas nie do uniknięcia dziś nie mają już raczej racji bytu.</p>
+
+<p>Może być ciężko odróżnić podatność nadużycia funkcji oprogramowania od pozostałych dwóch kategorii. Np. zarówno podatności związane z wadami, jak i nadużyciami mogą wynikać z braków w procesie projektowania oprogramowania. Jednakże wady oprogramowania są jednoznacznie negatywne - nie mają cech pozytywnych w odniesieniu do bezpieczeństwa czy funkcjonalności - podczas gdy podatności na nadużycia funkcji oprogramowania są wynikiem dostarczania dodatkowych funkcji.</p>
+
+<p>Mogą mylić podatności na nadużycia w odniesieniu do funkcji, które można odblokowywać lub zablokowywać - w rozumieniu, że są konfigurowalne - a kwestie konfiguracji bezpieczeństwa. Kluczową różnicą jest to, że przy podatności na nadużycia ustawienia bezpieczeństwa umożliwiają lub blokują całą funkcję, a nie wpływają jedynie na bezpieczeństwo. Podatność wynikająca z konfiguracji bezpieczeństwa dotyczy wyłącznie bezpieczeństwa.</p>
+
+<p>Np. ustawienie blokujące używanie HTML w mailach ma ogromny wpływ na zarówno kwestię bezpieczeństwa, jak i funkcjonalności. W tym przypadku podatność w odniesieniu do ustawienia będzie podatnością związaną z nadużyciem. Ustawienie blokujące funkcję antiphishingową w kliencie pocztowym ma ogromny wpływ wyłącznie na bezpieczeństwo, więc podatność dot. takiego ustawienia byłaby określona jako podatność w związku z konfiguracją bezpieczeństwa.</p>
+
+<h2 id="Obecność_podatności">Obecność podatności</h2>
+
+<p>Żaden system nie jest w 100% bezpieczny: każdy system ma podatności. W danym momencie system może nie posiadać żadnych widocznych wad, ale podatności na problemy z konfiguracją bezpieczeństwa i nadużycia funkcji oprogramowania są zawsze obecne.</p>
+
+<p>Podatność na nadużycia w przypadku funkcji oprogramowania jest nieodłączna, ponieważ każda funkcjonalność musi być opierana na założeniach idyllicznych - a te założenia mogą zostać złamane mimo dołożenia ogromnych wysiłków i poniesienia sporych kosztów. Kwestie konfiguracji bezpieczeństwa są nie do uniknięcia z dwóch powodów.</p>
+
+<p>Po pierwsze, wiele ustawień konfiguracyjnych zwiększa bezpieczeństwo kosztem funkcjonalności, więc używanie najbezpieczniejszych ustawień może doprowadzić do bezużyteczności oprogramowania. Po drugie, wiele ustawień bezpieczeństwa ma zarówno pozytywne, jak i negatywne kosekwencje względem bezpieczeństwa.</p>
+
+<p>Przykładem jest dopuszczona liczba następujących po sobie, nieudanych prób logowania na konto użytkownika zanim zostanie ono zablokowane. Ustawiając ją na 1 uzyskalibyśmy najbezpieczniejszą opcję przeciw atakom opartym na zgadywaniu haseł, ale jednocześnie blokowalibyśmy legalnych użytkowników po tym, jak jednokrotnie wpisaliby złe hasło. Co więcej, prawdopodobnie zachęciłoby to do używania przez atakujących ataków typu denial-of-service z racji łatwości generowania pojedynczej, nieudanej próby logowania dla wszystkich kont użytkowników.</p>
+
+<p>Z powodu liczby nieuniknionych podatności w ustawieniach konfiguracji bezpieczeństwa i możliwości nadużyć funkcji oprogramowania plus liczby podatności na wady oprogramowania w systemie niezależnie od czasu, każdy system może posiadać dziesiątki, jak nie setki podatności w jednym tylko systemie.</p>
+
+<p>Te podatności prawdopodobnie posiadają zróżnicowane cechy. Część będzie łatwa do wykorzystania, podczas gdy inne będą możliwe do wykorzystania jedynie w sytuacji zaistnienia kombinacji wysoce nieprawdopodobnych warunków.</p>
+
+<p>Jedna podatność może skutkować dostępem do systemu na poziomie administratora, podczas gdy inna jedynie umożliwiać odczyt nieistotnego pliku.</p>
+
+<p>Ostatecznie organizacje muszą wiedzieć, jak trudno jest wykorzystać daną podatność i co się stanie w sytuacji, jeśli dojdzie do jej wykorzystania.</p>
+
+<h2 id="Podatności_stron_WWW">Podatności stron WWW</h2>
+
+<p>OWASP lub Projekt Bezpieczeństwa Otwartej Sieci (Open Web Security Project) to organizacja non-profit skoncentrowana na zwiększaniu bezpieczeństwa oprogramowania i aplikacji WWW. Wg Open Web Application Security Project pod względem popularności XSS był <a class="external external-icon" href="https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf" rel="noopener">siódmą z najczęściej spotykanych podatności aplikacji WWW</a> w roku 2017.</p>
+
+<p>Organizacja publikuje listę najważniejszych podatności aplikacji WWW bazując na danych z różnych organizacji bezpieczeństwa.</p>
+
+<p><a href="/en-US/docs/Web/Security">Podatnosci aplikacji WWW</a> są priorytetowane pod względem możliwości wykorzystania, wykrywalności i wpływu na oprogramowanie, którym może być każdy CMS, jak WordPress, Joomla, Magneto, Woocommerce i inne.</p>
+
+<p>Poniżej przedstawiamy sześć najpopularniejszych podatności stron WWW, przed którymi musisz się chronić.</p>
+
+<p>1. SQL Injections<br>
+ 2. <a href="/en-US/docs/Glossary/Cross-site_scripting">Cross Site Scripting (XSS)</a><br>
+ 3. Broken Authentication &amp; Session Management -<a href="https://developer.mozilla.org/en-US/docs/Archive/IdentityManager"> IdentityManager</a><br>
+ 4. Insecure Direct Object References -<a href="https://developer.mozilla.org/en-US/docs/Glossary/DOM"> DOM (Document Object Model)</a><br>
+ 5. Security Misconfiguration<br>
+ 6. <a href="/en-US/docs/Glossary/CSRF">Cross-Site Request Forgery (CSRF) </a></p>
+
+<h2 id="Zobacz_również">Zobacz również</h2>
+
+<ul>
+ <li><a class="external" href="https://www.owasp.org/">Projekt Bezpieczeństwa Otwartej Sieci (OWASP)</a></li>
+ <li><a href="https://cve.mitre.org/">Popularne Podatności i Narażenia (CVE)</a></li>
+ <li><a href="https://secure.wphackedhelp.com/blog/wordpress-vulnerabilities-how-to-fix-guide-tools/">Popularne Podatności Bezpieczeństwa WordPressa</a></li>
+ <li><a href="https://en.wikipedia.org/wiki/Vulnerability_database">Baza danych podatności</a></li>
+</ul>
+
+<div class="originaldocinfo">
+<h3 id="Original_Document_Information" name="Original_Document_Information">Informacja o dokumentacji źródłowej</h3>
+
+<ul>
+ <li>Autorzy: Elizabeth LeMay, Karen Scarfone i Peter Mell</li>
+ <li>Tytuł: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities</li>
+ <li>Data ostatniej modyfikacji: July 2012</li>
+ <li>Informacja o prawach autorskich: Niniejszy dokument nie podlega prawom autorskim.</li>
+</ul>
+</div>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/pl/web/bezpieczeństwo/same-origin_policy/index.html b/files/pl/web/bezpieczeństwo/same-origin_policy/index.html
new file mode 100644
index 0000000000..23f296444e
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/same-origin_policy/index.html
@@ -0,0 +1,277 @@
+---
+title: Reguła tego samego pochodzenia (Same-origin policy)
+slug: Web/Bezpieczeństwo/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
+---
+<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>
diff --git a/files/pl/web/bezpieczeństwo/subresource_integrity/index.html b/files/pl/web/bezpieczeństwo/subresource_integrity/index.html
new file mode 100644
index 0000000000..69f20709ec
--- /dev/null
+++ b/files/pl/web/bezpieczeństwo/subresource_integrity/index.html
@@ -0,0 +1,163 @@
+---
+title: Integralność podzasobów (Subresource Integrity)
+slug: Web/Bezpieczeństwo/Subresource_Integrity
+tags:
+  - Bezpieczeństwo
+  - HTML
+  - HTTP
+  - Wstęp
+  - bezpieczeństwo aplikacji WWW
+translation_of: Web/Security/Subresource_Integrity
+---
+<p><span class="seoSummary"><strong>Subresource Integrity</strong> (SRI), w wolnym tłumaczeniu "integralność podzasobów", to funkcja bezpieczeństwa umożliwiająca przeglądarkom weryfikowanie, czy zasoby, które przechwytują (np. z<a href="/en-US/docs/Glossary/CDN"> CDN</a>) docierają do nich bez nieporządanych zmian. Działanie takie jest możliwe dzięki używaniu hasha kryptograficznego, z którym przechwycony zasób musi być zgodny.</span></p>
+
+<div class="note">
+<p><strong>Notka</strong>: W celu weryfikacji integralności podzasobów danych przekazywanych ze źródła innego, niż dokument w którym są osadzane przeglądarki dodatkowo sprawdzają źródło poprzez międzyźródłowe udostępnianie zasobów, tzw. <a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing (CORS)</a>. Dzięki temu upewniają się, że pochodzenie (origin) oferujące dane zasoby pozwala na udostępnianie ich z innym, sprecyfizowanym originem.</p>
+</div>
+
+<h2 id="Korzyści_wynikające_z_Subresource_Integrity">Korzyści wynikające z "Subresource Integrity"</h2>
+
+<p>Używając {{Glossary("CDN", "Content Delivery Networks (CDNs)")}} do hostowania plików, jak np. skrypty czy arkusze stylów, które są udostępnianie pośród licznych stron WWW można polepszyć wydajność strony i zachować przepustowość łącza. Jednakże, używając CDNów ryzykujemy, że jeśli atakujący przejmie kontrolę nad CDNem to może wprowadzić szkodliwą zawartość do plików na CDNie (lub zupełnie je zastąpić) i przez to potencjalnie może zaatakować wszystkie strony, które przechwytują pliki z tego CDNu.</p>
+
+<p>"Subresource Integrity" pozwala na ograniczenie ryzyka ataków tego typu poprzez zapewnienie, że pliki które dana aplikacja, bądź dokument WWW przechwytują (m. in. z CDNu) zostały dostarczone bez udziału trzeciej strony, która "wzbogaciła" nasze dane o dodatkową treść oraz bez żadnych, jakichkolwiek innych zmian w przesyłanych plikach.</p>
+
+<h2 id="Używanie_Subresource_Integrity">Używanie "Subresource Integrity"</h2>
+
+<p>Korzystanie z funkcji "Subresource Integrity" jest możliwe przez określenie hasha zakodowanego kryptograficznie w base64 zasobu (pliku), który przeglądarka ma przechwycić, z wartością atrybutu <code>integrity</code> danego elementu {{HTMLElement("script")}} or {{HTMLElement("link")}}.</p>
+
+<p>Wartość <code>integrity</code> zaczyna się od co najmniej jednego stringu, przy czym każdy string zawiera prefiks wskazujący na konkretny algorytm hashowy (obecnie dozwolonymi prefiksami są <code>sha256</code>, <code>sha384</code>, i <code>sha512</code>), następnie opatrzony myślnikiem i zakończony aktualnym hashem zakodowanym w base64.</p>
+
+<div class="note">
+<p><strong>Notka</strong>: Wartość <strong>integrity </strong>może zawierać liczne hashe oddzielone białymi znakami. Zasób zostanie załadowany, jeśli dopasuje się z jednym z tych hashów.</p>
+</div>
+
+<p>Przykładowy string <code>integrity</code> z hashem sha384 zakodowanym w base64:</p>
+
+<pre>sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+</pre>
+
+<p>Więc <code>oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> to część "hashowa", a prefiks <code>sha384</code> wskazuje, że jest to hash sha384.</p>
+
+<div class="note">
+<p><strong>Notka</strong>: Część "hashowa" wartości <code>integrity</code> jest, mówić ściśle, <em><strong>skrótem kryptograficznym</strong></em> formowanym przez zastosowanie określonych funkcji hashowych do danego outputu (np. skryptu lub arkuszu stylów). Zwykle używa się skrótu "hash" do określania <em>skrótu kryptograficznego</em>, więc w taki sposób to określenie jest używane w niniejszym artykule.</p>
+</div>
+
+<h3 id="Narzędzia_do_generowania_hashów_SRI">Narzędzia do generowania hashów SRI</h3>
+
+<p>Możesz generować hashe SRI z konsoli z <strong>openssl </strong>używając wywołania polecenia, jak:</p>
+
+<pre class="brush: bash">cat <strong>FILENAME.js</strong> | openssl dgst -sha384 -binary | openssl base64 -A</pre>
+
+<p>lub z <strong>shasum</strong> używając wywołania polecenia, jak:</p>
+
+<pre class="brush: bash">shasum -b -a 384 <strong>FILENAME.js</strong> | awk '{ print $1 }' | xxd -r -p | base64
+</pre>
+
+<div class="note">
+<p><strong>Notka</strong>:</p>
+
+<ul>
+ <li>Krok z <code>xxd</code> pobiera dane wyjściowe w postaci heksadecymalnej z <code>shasum</code> i zamienia je na zapis binarny.</li>
+ <li>Krok z <code>awk</code> jest niezbędny, ponieważ <code>shasum</code> w danych wyjściowych przekazuje zahashowaną nazwę pliku do <code>xxd</code>. Trzeba liczyć się z katastrofalnymi konsekwencjami, jeśli nazwa pliku zawiera znaki występujące w zapisie heksadecymalnym - <code>xxd</code> odkoduje ten zapis i przekaże go do <code>base64</code>.</li>
+</ul>
+</div>
+
+<p>Warto wiedzieć, że dostępny na <a href="https://www.srihash.org/">https://www.srihash.org/</a> <strong>SRI Hash Generator</strong> to narzędzie online umożliwiające generowanie hashy SRI.</p>
+
+<h3 id="Zasady_bezpieczeństwa_zawartości_i_Integralności_podzasobówContent_Security_Policy_Subresource_Integrity">Zasady bezpieczeństwa zawartości i Integralności podzasobów(Content Security Policy &amp; Subresource Integrity)</h3>
+
+<p>Możesz skorzystać z Zasad bezpieczeństwa zawartości (<a href="/en-US/docs/Web/HTTP/CSP">Content Security Policy</a>), by skonfigurować swój serwer, żeby wymuszał by określone typy plików wymagały stosowania Subresource Integrity. Aby to zrobić użyj dyrektywy {{CSP("require-sri-for")}} w swoim nagłówku CSP, np.:</p>
+
+<pre>Content-Security-Policy: require-sri-for script;</pre>
+
+<p>Dzięki temu zapisowi każda próba załadowania JavaScript powiedzie się jedynie, jeśli informacja o Subresource Integrity znajduje się na miejscu, a testy integralności zakończą się sukcesem.</p>
+
+<p>Możesz również określić, że SRI powinno być stosowane podczas ładowania arkuszy stylów:</p>
+
+<pre>Content-Security-Policy: require-sri-for style;</pre>
+
+<p>Możesz również określić zarówno <code>script</code>, jak i <code>style</code> aby wymagać SRI przy obu typach plików.</p>
+
+<h3 id="Udostępnianie_zasobów_między_źródłami_i_Integralności_podzasobów_Cross-Origin_Resource_Sharing_Subresource_Integrity">Udostępnianie zasobów między źródłami i Integralności podzasobów (Cross-Origin Resource Sharing &amp; Subresource Integrity)</h3>
+
+<p>Celem weryfikacji integralności podzasobów danych pochodzących z originu innego, niż dokument, w którym są osadzone, przeglądarki dodatkowo sprawdzają dane za pomocą CORS (<a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a>). Upewniają się, że origin dostarczający dane pozwala na udostępnianie wnioskującemu originowi. Wtedy dane muszą zostać dostarczone z nagłówkiem <code><a href="/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin">Access-Control-Allow-Origin</a></code>, co pozwala na udostępnienie danych wnioskującemu originowi, np.:</p>
+
+<pre>Access-Control-Allow-Origin: *</pre>
+
+<h2 id="Przykłady">Przykłady</h2>
+
+<p>W poniższych przykładach przyjmimy, że <code id="sriSnippet">oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> to oczekiwany hash SHA-384 (skrót) określonego skryptu <code>example-framework.js</code> i że istnieje kopia skryptu hostowana na <code>https://example.com/example-framework.js</code>.</p>
+
+<h3 id="Subresource_Integrity_with_the_&lt;script>_element">Subresource Integrity with the &lt;script&gt; element</h3>
+
+<p>Możesz użyć niniejszego elementu {{HTMLElement("script")}}, by nakazać przeglądarce, aby przed wywołaniem skryptu <code>https://example.com/example-framework.js</code> najpierw porównała skrypt z oczekiwanym hashem i zweryfikowała, że są dopasowane.</p>
+
+<pre class="brush: html">&lt;script src="https://example.com/example-framework.js"
+        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+        crossorigin="anonymous"&gt;&lt;/script&gt;</pre>
+
+<div class="note">
+<p><strong>Notka</strong>: By dowiedzieć się więcej nt. zastosowania atrybutu <code>crossorigin</code> sprawdź <a href="/en-US/docs/Web/HTML/CORS_settings_attributes">atrybuty ustawień CORS</a>.</p>
+</div>
+
+<h2 id="Jak_przeglądarki_radzą_sobie_z_Subresource_Integrity">Jak przeglądarki radzą sobie z "Subresource Integrity"</h2>
+
+<p>Przeglądarki radzą sobie z SRI poprzez podjęcie poniższych działań:</p>
+
+<ol>
+ <li>
+  <p>Kiedy przeglądarka napotka element {{HTMLElement("script")}} lub {{HTMLElement("link")}} z atrybutem <code>integrity</code>, przed wywołaniem skryptu lub przed zastosowaniem jakiegokolwiek arkusza stylów określonego przez element {{HTMLElement("link")}}, przeglądarka musi najpierw porównać skrypt lub arkusz stylów do oczekiwanego hasha podanego w wartości <code>integrity</code>.</p>
+
+  <p class="note"><strong>Notka</strong>: Celem weryfikacji integralności podzasobów danych dostarczanych z originu innego, niż dokument, w którym zostały osadzone, przeglądarki dodatkowo sprawdzają dane poprzez stosowanie <a href="/en-US/docs/Web/HTTP/CORS">CORS</a>, aby upewnić się, że origin dostarczający dane pozwala na udostępnianie ich z wnioskującym originem.</p>
+ </li>
+ <li>Jeśli skrypt lub arkusz stylów nie pasuje do odpowiadającej mu wartości <code>integrity</code>, przeglądarka musi odmówić wywołania skryptu lub uwzględnienia arkusza stylów i zamiast tego musi zwrócić błąd sieciowy wskazujący, że nie powiodło się przechwycenie tego skryptu lub arkusza stylów.</li>
+</ol>
+
+<h2 id="Specyfikacje">Specyfikacje</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">Specyfikacja</th>
+   <th scope="col">Status</th>
+   <th scope="col">Komentarz</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName('Subresource Integrity')}}</td>
+   <td>{{Spec2('Subresource Integrity')}}</td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch')}}</td>
+   <td>{{Spec2('Fetch')}}</td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Kompatybilność_z_przeglądarkami">Kompatybilność z przeglądarkami</h2>
+
+<h3 id="&lt;script_integrity>">&lt;script integrity&gt;</h3>
+
+<p class="hidden">Tabela kompatybilności na tej stronie jest generowana na podstawie danych strukturalnych. Jeśli chcesz ją współtworzyć, sprawdź <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> i wyślij nam pull requesta.</p>
+
+<p>{{Compat("html.elements.script.integrity")}}</p>
+
+<h3 id="CSP_require-sri-for">CSP: require-sri-for</h3>
+
+<p class="hidden">Tabela kompatybilności na tej stronie jest generowana na podstawie danych strukturalnych. Jeśli chcesz ją współtworzyć, sprawdź <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> i wyślij nam pull requesta.</p>
+
+<p>{{Compat("http.headers.csp.require-sri-for")}}</p>
+
+<h2 id="Zobacz_również">Zobacz również</h2>
+
+<ul>
+ <li>Zasady bezpieczeństwa zawartości (Content Security Policy)</li>
+ <li>{{httpheader("Content-Security-Policy")}}</li>
+ <li><a href="https://frederik-braun.com/using-subresource-integrity.html" id="page-title">CDN, który Cię nie zXXSuje: Używanie Subresource Integrity</a></li>
+ <li><a href="https://w3c-test.org/subresource-integrity/subresource-integrity.html" id="w3c-test">Test na Subresource Integrity z W3C</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>