Udostępnianie zasobów między źródłami — Cross-origin resource sharing

Udostępnianie zasobów między źródłami ( CORS ) to mechanizm, który umożliwia żądanie ograniczonych zasobów na stronie sieci Web z innej domeny spoza domeny, z której został udostępniony pierwszy zasób.

Na stronie internetowej można swobodnie umieszczać obrazy z różnych źródeł, arkusze stylów , skrypty, ramki iframe i filmy. Niektóre żądania „międzydomenowe”, w szczególności żądania Ajax , są domyślnie zabronione przez politykę bezpieczeństwa tego samego pochodzenia . CORS definiuje sposób, w jaki przeglądarka i serwer mogą współdziałać w celu określenia, czy zezwalanie na żądanie cross-origin jest bezpieczne. Pozwala na większą swobodę i funkcjonalność niż żądania czysto tego samego pochodzenia, ale jest bezpieczniejszy niż po prostu zezwalanie na wszystkie żądania z różnych źródeł.

Specyfikacja CORS jest częścią standardu Fetch Living Standard WHATWG . Ta specyfikacja opisuje, w jaki sposób CORS jest obecnie zaimplementowany w przeglądarkach. Wcześniejsza specyfikacja została opublikowana jako zalecenie W3C .

Przegląd techniczny

Ścieżka XMLHttpRequest (XHR) przez CORS.

W przypadku metod żądań Ajax i HTTP, które mogą modyfikować dane (zwykle metody HTTP inne niż GET lub do użycia POST z pewnymi typami MIME ), specyfikacja nakazuje przeglądarkom „wstępne sprawdzanie” żądania, pozyskując obsługiwane metody z serwera za pomocą żądania HTTP OPTIONS metody, a następnie, po „zatwierdzeniu” przez serwer, wysłanie rzeczywistego żądania za pomocą rzeczywistej metody żądania HTTP. Serwery mogą również powiadamiać klientów, czy „poświadczenia” (w tym pliki cookie i dane uwierzytelniania HTTP) powinny być wysyłane wraz z żądaniami.

Prosty przykład

Załóżmy, że użytkownik odwiedza witrynę http://www.example.com, a strona próbuje wysłać żądanie z różnych źródeł, aby pobrać dane użytkownika z witryny http://service.example.com. Przeglądarka zgodna z CORS spróbuje wysłać żądanie cross-origin do service.example.com w następujący sposób.

Przeglądarka wysyła żądanie GET z dodatkowym Origin nagłówkiem HTTP do service.example.com zawierającej domenę, która obsługiwała stronę nadrzędną:
```
Origin: http://www.example.com
```
Serwer pod adresem service.example.com może odpowiedzieć:
- Access-Control-Allow-OriginŻądane dane wraz z nagłówkiem (ACAO) w odpowiedzi wskazującym na żądania ze źródła są dozwolone. Na przykład w tym przypadku powinno to być:
```
Access-Control-Allow-Origin: http://www.example.com
```
- Access-Control-Allow-OriginŻądane dane wraz z nagłówkiem (ACAO) z symbolem wieloznacznym wskazującym, że żądania ze wszystkich domen są dozwolone:
```
Access-Control-Allow-Origin: *
```
- Strona błędu, jeśli serwer nie zezwala na żądanie cross-origin

Zasada „samego pochodzenia” z symbolami wieloznacznymi jest odpowiednia, gdy strona lub odpowiedź interfejsu API jest uważana za całkowicie publiczną treść i ma być dostępna dla wszystkich, łącznie z dowolnym kodem w dowolnej witrynie. Przykładem jest ogólnodostępna czcionka internetowa w publicznej usłudze hostingowej, takiej jak Google Fonts .

Zasada tego samego pochodzenia z symbolami wieloznacznymi jest również szeroko i odpowiednio stosowana w modelu obsługi obiektów , w którym strony mają niemożliwe do odgadnięcia adresy URL i mają być dostępne dla każdego, kto zna tajemnicę.

Wartość „*” jest wyjątkowa, ponieważ nie zezwala na żądania dostarczania poświadczeń, co oznacza, że nie zezwala na uwierzytelnianie HTTP, certyfikaty SSL po stronie klienta ani pliki cookie w żądaniu międzydomenowym.

Należy zauważyć, że w architekturze CORS nagłówek Access-Control-Allow-Origin jest ustawiany przez zewnętrzną usługę internetową ( service.example.com ), a nie przez oryginalny serwer aplikacji internetowych ( www.example.com ). W tym przypadku service.example.com używa CORS, aby umożliwić przeglądarce autoryzację www.example.com na wysyłanie żądań do service.example.com .

Jeśli witryna określa nagłówek „Access-Control-Allow-Credentials:true”, witryny innych firm mogą być w stanie wykonywać uprzywilejowane działania i pobierać poufne informacje. Nawet jeśli tak się nie stanie, osoby atakujące mogą być w stanie ominąć wszelkie kontrole dostępu oparte na protokole IP, korzystając z proxy za pośrednictwem przeglądarek użytkowników.

Przykład przed lotem

Podczas wykonywania niektórych typów międzydomenowych żądań Ajax nowoczesne przeglądarki obsługujące mechanizm CORS zainicjują dodatkowe żądanie „przeglądu wstępnego”, aby określić, czy mają uprawnienia do wykonania akcji. Żądania między źródłami są w ten sposób wstępnie sprawdzane, ponieważ mogą mieć wpływ na dane użytkownika.

OPTIONS /
Host: service.example.com
Origin: http://www.example.com
Access-Control-Request-Method: PUT

Jeśli service.example.com chce zaakceptować akcję, może odpowiedzieć następującymi nagłówkami:

Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: PUT, DELETE

Przeglądarka wyśle wtedy rzeczywiste żądanie. Jeśli service.example.com nie akceptuje żądań między witrynami z tego źródła, odpowie z błędem na żądanie OPTIONS, a przeglądarka nie wyśle rzeczywistego żądania.

Nagłówki

Nagłówki HTTP odnoszące się do CORS to:

Nagłówki żądań

Origin
Access-Control-Request-Method
Access-Control-Request-Headers

Nagłówki odpowiedzi

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Expose-Headers
Access-Control-Max-Age
Access-Control-Allow-Methods
Access-Control-Allow-Headers

Obsługa przeglądarki

CORS jest obsługiwany przez wszystkie przeglądarki oparte na następujących silnikach układu:

Przeglądarki oparte na Blink i Chromium ( Chrome 28+, Opera 15+, Amazon Silk , Android 4.4+ WebView i Qt WebEngine)
Gecko 1.9.1 (Firefox 3.5, SeaMonkey 2.0) i nowsze.
MSHTML/Trident 6.0 (Internet Explorer 10) ma natywną obsługę. MSHTML/Trident 4.0 i 5.0 (Internet Explorer 8 i 9) zapewniają częściowe wsparcie za pośrednictwem obiektu XDomainRequest.
Przeglądarki oparte na Presto (Opera) implementują CORS od Opery 12.00 i Opera Mobile 12, ale nie Opery Mini .
WebKit (niepewna wersja początkowa, Safari 4 i nowsze, Google Chrome 3 i nowsze, prawdopodobnie starsze).
Microsoft Edge Wszystkie wersje.

Historia

Obsługa cross-origin została pierwotnie zaproponowana przez Matta Oshry'ego, Brada Portera i Michaela Bodella z Tellme Networks w marcu 2004 roku do włączenia do VoiceXML 2.1, aby umożliwić bezpieczne żądania danych cross-origin przez przeglądarki VoiceXML. Mechanizm został uznany za ogólny i niespecyficzny dla VoiceXML, a następnie został podzielony na implementację NOTE. Grupa Robocza WebApps W3C z udziałem głównych dostawców przeglądarek rozpoczęła formalizację NOTATKI w W3C Working Draft na drodze do formalnego statusu Rekomendacji W3C .

W maju 2006 został przedłożony pierwszy projekt roboczy W3C. W marcu 2009 roku projekt został przemianowany na „Cross-Origin Resource Sharing”, aw styczniu 2014 roku został przyjęty jako Rekomendacja W3C.

CORS vs JSONP

CORS może być wykorzystany jako nowoczesna alternatywa dla wzorca JSONP . Korzyści z CORS to:

Podczas gdy JSONP obsługuje tylko GETmetodę żądania, CORS obsługuje również inne typy żądań HTTP.
CORS umożliwia programiście internetowym używanie zwykłego XMLHttpRequest , który obsługuje lepszą obsługę błędów niż JSONP.
Chociaż JSONP może powodować problemy z wykonywaniem skryptów między witrynami (XSS) w przypadku naruszenia bezpieczeństwa witryny zewnętrznej, mechanizm CORS umożliwia witrynom ręcznym analizowanie odpowiedzi w celu zwiększenia bezpieczeństwa.

Główną zaletą JSONP była możliwość pracy na starszych przeglądarkach, które poprzedzały obsługę CORS ( Opera Mini i Internet Explorer 9 i wcześniejsze). CORS jest teraz obsługiwany przez większość nowoczesnych przeglądarek internetowych.

Languages

In other projects