Fetch: požadavky jiného původu

Jestliže poÅ¡leme požadavek fetch na jiné webové sídlo, pravdÄ›podobnÄ› neuspÄ›je.

Zkusme například stáhnout http://example.com:

try {
  await fetch('http://example.com');
} catch(err) {
  alert(err); // Failed to fetch
}

Jak jsme očekávali, stažení selhalo.

Klíčovým konceptem je zde původ – trojice doména/port/protokol.

Požadavky jiného (křížového) původu – ty, které jsou posílány na jinou doménu (nebo i subdoménu), protokol nebo port – vyžadují speciální hlavičky ze vzdálené strany.

Tato politika se nazývá „CORS“: Cross-Origin Resource Sharing – sdílení zdrojů křížového původu.

Proč je CORS zapotřebí? Stručná historie

CORS existuje proto, aby chránila internet před zlými hackery.

Teď vážně. Udělejme si kraťoučkou odbočku do historie.

Mnoho let nemohl skript z jednoho sídla přistupovat k obsahu z jiného sídla.

Toto jednoduché, ale silné pravidlo bylo základem internetové bezpečnosti. Například zlý skript z webového sídla hacker.com nemohl pÅ™istupovat k uživatelovÄ› poÅ¡tovní schránce na webovém sídle gmail.com. Lidé mÄ›li pocit bezpečí.

Navíc JavaScript v té době neměl žádné speciální metody k provádění síťových požadavků. Byl to jen jazyk „na hraní“, sloužící k dekoraci webových stránek.

Jenže vývojáři webů požadovali další možnosti. Byla vyvinuta celá řada triků, jak toto omezení obejít a odesílat požadavky na jiná webová sídla.

Používání formulářů

Jedním způsobem, jak komunikovat s jiným serverem, bylo odeslat na nÄ›j <form>. Lidé ho vkládali do <iframe>, aby zůstali na aktuální stránce, například:

<!-- cíl formuláře -->
<iframe name="iframe"></iframe>

<!-- formulář může být dynamicky vygenerován a odeslán JavaScriptem -->
<form target="iframe" method="POST" action="http://jiny-server.com/…">
  ...
</form>

I bez síťových metod tedy bylo možné vytvoÅ™it požadavek GET/POST na jiné sídlo, neboÅ¥ formuláře mohou posílat data kamkoli. Protože vÅ¡ak je zakázáno pÅ™istupovat k obsahu <iframe> z jiného sídla, nebylo možné načíst odpověď.

Abychom byli přesní, i na to ve skutečnosti existovaly triky, které vyžadovaly speciální skripty jak ve vnitřním rámu, tak na stránce. Komunikace s vnitřním rámem tedy byla technicky možná. Dnes již nemá smysl zabíhat do detailů, nechme tyto dinosaury v klidu spát.

Používání skriptů

Dalším trikem bylo použití značky script. Skript může mít libovolný src, s libovolnou doménou, například <script src="http://jiny-server.com/…">. Je možné spustit skript z libovolného webového sídla.

Jestliže webové sídlo, napÅ™. jiny-server.com, mÄ›lo v úmyslu zviditelnit svá data tomuto druhu přístupu, používal se tzv. protokol „JSONP“ („JSON with padding“ – „JSON s vycpávkou“).

Fungovalo to následovně.

ŘeknÄ›me, že na naÅ¡em sídle potÅ™ebujeme získat data z http://jiny-server.com, například informace o počasí:

1. Nejprve deklarujeme globální funkci, která tato data pÅ™ijme, napÅ™. počasíZískáno.

   // 1. Deklarujeme funkci, která bude zpracovávat data o počasí
   function počasíZískáno({ teplota, vlhkost }) {
     alert(`teplota: ${teplota}, vlhkost: ${vlhkost}`);
   }

2. Pak vytvoříme značku <script> se src="http://jiny-server.com/weather.json?callback=počasíZískáno". Název naší funkce vložíme do URL parametru callback.

   let skript = document.createElement('script');
   skript.src = `http://jiny-server.com/weather.json?callback=počasíZískáno`;
   document.body.append(skript);

3. Vzdálený server jiny-server.com dynamicky vygeneruje skript, který volá počasíZískáno(...) s daty, která chce, abychom získali.

   // Očekávaná odpověď ze serveru vypadá takto:
   počasíZískáno({
     teplota: 25,
     vlhkost: 78
   });

4. Když se vzdálený skript načte a spustí, vyvolá se počasíZískáno, a protože je to naÅ¡e funkce, máme data.

To funguje a neporušuje to bezpečnost, protože obě strany souhlasily, že si budou data takto posílat. A když obě strany souhlasily, nemůže to být hacknutí. Některé služby takový přístup poskytují dodnes, protože funguje i ve velmi starých prohlížečích.

Po nějaké době se v prohlížečovém JavaScriptu objevily síťové metody.

Požadavky jiného původu byly nejdříve zakázány. Po dlouhých diskusích však byly nakonec povoleny, ale s tím, že nové schopnosti vyžadují výslovné povolení od serveru, uvedené ve speciálních hlavičkách.

Bezpečné požadavky

Požadavky jiného původu se dělí na dva druhy:

1. Bezpečné požadavky.
2. Všechny ostatní.

Vytváření bezpečných požadavků je jednodušší, začněme tedy s nimi.

Požadavek je bezpečný, jestliže splňuje tyto dvě podmínky:

1. Bezpečná metoda: GET, POST nebo HEAD.
2. Bezpečné hlavičky – jsou povoleny jedině tyto vlastní hlavičky:
   • Accept,
   • Accept-Language,
   • Content-Language,
   • Content-Type s hodnotou application/x-www-form-urlencoded, multipart/form-data nebo text/plain.

Jakýkoli jiný požadavek se považuje za „nebezpečný“. Například požadavek s metodou PUT nebo s HTTP hlavičkou API-Key tato omezení nesplňuje.

Podstatným rozdílem je, že bezpečný požadavek je možné vytvoÅ™it pomocí <form> nebo <script>, bez jakýchkoli speciálních metod.

I velmi starý server by tedy měl být připraven přijmout bezpečný požadavek.

Naproti tomu požadavky s nestandardními hlavičkami nebo napÅ™. s metodou DELETE nemohou být vytvoÅ™eny tímto způsobem. JavaScript dlouho nedokázal takové požadavky vytvářet. Starší server tedy může pÅ™edpokládat, že takové požadavky pÅ™icházejí z privilegovaného zdroje, „protože webová stránka je není schopna posílat“.

Když se pokoušíme vytvořit nebezpečný požadavek, prohlížeč pošle speciální „předběžný“ („preflight“) požadavek, který se zeptá serveru: souhlasíš s přijetím takového požadavku jiného původu, nebo ne?

A pokud k tomu server výslovně nedá souhlas v hlavičkách odpovědi, nebezpečný požadavek nebude poslán.

Nyní pojďme do detailů.

CORS pro bezpečné požadavky

Pokud požadavek je z jiného původu, prohlížeč do nÄ›j vždy pÅ™idá hlavičku Origin.

Například pokud posíláme požadavek na https://kdekoli.com/request z https://javascript.info/page, hlavičky budou vypadat takto:

GET /request
Host: kdekoli.com
Origin: https://javascript.info
...

Jak vidíte, hlavička Origin obsahuje jedinÄ› původ (doménu/protokol/port) bez cesty.

Server může Origin prozkoumat, a pokud s pÅ™ijetím takového požadavku souhlasí, pÅ™idá do odpovÄ›di speciální hlavičku Access-Control-Allow-Origin. Tato hlavička by mÄ›la obsahovat povolený původ (v naÅ¡em případÄ› https://javascript.info) nebo hvÄ›zdičku *. Pak je odpověď úspěšná. V opačném případÄ› nastane chyba.

Prohlížeč zde hraje roli důvěryhodného prostředníka:

1. ZajiÅ¡Å¥uje, že v požadavku jiného původu je odeslán správný Origin.
2. Ověří, zda odpověď obsahuje Access-Control-Allow-Origin s povolením. Pokud ano, povolí JavaScriptu přístup k odpovÄ›di, v opačném případÄ› vyvolá chybu.

Zde je příklad odpovědi serveru s povolením:

200 OK
Content-Type:text/html; charset=UTF-8
Access-Control-Allow-Origin: https://javascript.info

Hlavičky odpovědi

U požadavku jiného původu může JavaScript standardně přistupovat jen k tzv. „bezpečným“ hlavičkám odpovědi:

• Cache-Control
• Content-Language
• Content-Length
• Content-Type
• Expires
• Last-Modified
• Pragma

Přístup ke kterékoli jiné hlavičce vyvolá chybu.

Aby server povolil JavaScriptu přístup k jiným hlavičkám odpovÄ›di, musí poslat hlavičku Access-Control-Expose-Headers, která obsahuje seznam názvů nebezpečných hlaviček, které mají být zpřístupnÄ›ny, oddÄ›lených čárkou.

Příklad:

200 OK
Content-Type:text/html; charset=UTF-8
Content-Length: 12345
Content-Encoding: gzip
API-Key: 2c9de507f2c54aa1
Access-Control-Allow-Origin: https://javascript.info
Access-Control-Expose-Headers: Content-Encoding,API-Key

S takovou hlavičkou Access-Control-Expose-Headers má skript dovoleno číst hlavičky odpovÄ›di Content-Encoding a API-Key.

„Nebezpečné“ požadavky

Můžeme použít jakoukoli HTTP metodu: nejenom GET/POST, ale také PATCH, DELETE i jiné.

Před nějakou dobou si nikdo neuměl ani představit, že by webová stránka mohla vytvářet takové požadavky. Stále tedy mohou existovat webové služby, které nestandardní metodu považují za signál: „Tohle není prohlížeč.“ Mohou to vzít v úvahu, když budou ověřovat přístupová práva.

Abychom tedy předešli nedorozumění, když jde o „nebezpečný“ požadavek, jaký nemohl být v dřívější době vytvořen, prohlížeč takový požadavek neposílá okamžitě. Napřed pošle předběžný požadavek, tzv. „preflight“, kterým požádá o povolení.

PÅ™edběžný požadavek používá metodu OPTIONS, nemá žádné tÄ›lo a má tÅ™i hlavičky:

• Hlavička Access-Control-Request-Method obsahuje metodu nebezpečného požadavku.
• Hlavička Access-Control-Request-Headers poskytuje seznam jeho nebezpečných HTTP hlaviček, oddÄ›lených čárkou.
• Hlavička Origin sdÄ›luje, odkud požadavek pÅ™iÅ¡el (napÅ™. https://javascript.info).

Pokud server souhlasí s obsluhováním takových požadavků, měl by poslat odpověď s prázdným tělem, statusem 200 a hlavičkami:

• Access-Control-Allow-Origin musí být buď *, nebo požadovaný původ, napÅ™. https://javascript.info, který má být povolen.
• Access-Control-Allow-Methods musí obsahovat povolenou metodu.
• Access-Control-Allow-Headers musí obsahovat seznam povolených hlaviček.
• Navíc hlavička Access-Control-Max-Age může specifikovat čas v sekundách, jak dlouho si server bude povolení pamatovat. Prohlížeč tedy v tomto čase nebude muset posílat pÅ™edběžné požadavky pÅ™ed dalšími požadavky, které splňují daná povolení.

Podívejme se krok za krokem, jak to funguje, na příkladu požadavku PATCH jiného původu (tato metoda se často používá k aktualizaci dat):

let odpověď = await fetch('https://site.com/service.json', {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json',
    'API-Key': 'secret'
  }
});

Tento požadavek má tři důvody, proč je nebezpečný (stačil by jeden):

• Metoda PATCH.
• Content-Type není jeden z: application/x-www-form-urlencoded, multipart/form-data, text/plain.
• „Nebezpečná“ hlavička API-Key.

Krok 1 (předběžný požadavek)

Před odesláním takového požadavku prohlížeč sám o sobě odešle předběžný požadavek, který vypadá následovně:

OPTIONS /service.json
Host: site.com
Origin: https://javascript.info
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: Content-Type,API-Key

• Metoda: OPTIONS.
• Cesta je pÅ™esnÄ› stejná, jako v hlavním požadavku: /service.json.
• Speciální hlavičky jiného původu:
  • Origin – původ zdroje.
  • Access-Control-Request-Method – požadovaná metoda.
  • Access-Control-Request-Headers – seznam „nebezpečných“ hlaviček oddÄ›lených čárkou.

Krok 2 (předběžná odpověď)

Server by měl odpovědět statusem 200 a těmito hlavičkami:

• Access-Control-Allow-Origin: https://javascript.info
• Access-Control-Allow-Methods: PATCH
• Access-Control-Allow-Headers: Content-Type,API-Key

To umožní následnou komunikaci, jinak bude vyvolána chyba.

Pokud server v budoucnu očekává i jiné metody a hlavičky, má smysl je s předstihem povolit a zahrnout do seznamu.

Například tato odpověď povoluje také metody PUT, DELETE a další hlavičky:

200 OK
Access-Control-Allow-Origin: https://javascript.info
Access-Control-Allow-Methods: PUT,PATCH,DELETE
Access-Control-Allow-Headers: API-Key,Content-Type,If-Modified-Since,Cache-Control
Access-Control-Max-Age: 86400

Nyní prohlížeč vidí, že PATCH je v Access-Control-Allow-Methods a Content-Type,API-Key jsou v seznamu Access-Control-Allow-Headers, takže poÅ¡le hlavní požadavek.

Pokud je uvedena hlavička Access-Control-Max-Age s časem v sekundách, pak se pÅ™edběžná povolení na zadanou dobu uloží do pamÄ›ti. Uvedená odpověď bude v pamÄ›ti 86400 sekund (jeden den). Po tuto dobu se pÅ™ed dalšími požadavky nebude posílat pÅ™edběžný požadavek. Pokud budou splňovat uvedená povolení, budou odeslány rovnou.

Krok 3 (skutečný požadavek)

Když je předběžný požadavek úspěšný, prohlížeč vytvoří hlavní požadavek. Je to stejný proces jako u bezpečných požadavků.

Hlavní požadavek obsahuje hlavičku Origin (protože je jiného původu):

PATCH /service.json
Host: site.com
Content-Type: application/json
API-Key: secret
Origin: https://javascript.info

Krok 4 (skutečná odpověď)

Server by nemÄ›l zapomenout pÅ™idat do hlavní odpovÄ›di Access-Control-Allow-Origin. Úspěšný pÅ™edběžný požadavek ho z toho nevyvazuje:

Access-Control-Allow-Origin: https://javascript.info

Pak je JavaScript schopen načíst hlavní odpověď serveru.

Přihlašovací údaje

Požadavek jiného původu vytvořený JavaScriptovým kódem standardně neobsahuje žádné přihlašovací údaje (cookies nebo HTTP autentifikaci).

Pro HTTP požadavky je to neobvyklé. Požadavek na http://site.com je zpravidla doprovázen vÅ¡emi cookies z této domény. Požadavky jiného původu vytvoÅ™ené metodami v JavaScriptu jsou vÅ¡ak výjimkou.

Například fetch('http://jiny-server.com') nepoÅ¡le žádné cookies, dokonce ani ty (!), které patří doménÄ› jiny-server.com.

Proč?

Je to proto, že požadavek s přihlašovacími údaji je mnohem silnější než bez nich. Kdyby byly povoleny, poskytly by JavaScriptu plnou moc jednat jménem uživatele a skrz jeho přihlašovací údaje přistupovat k důvěrným informacím.

Co když server opravdu skriptu věří natolik, že mu to chce umožnit? Pak musí v další hlavičce výslovně povolit požadavky s přihlašovacími údaji.

Abychom ve fetch poslali pÅ™ihlaÅ¡ovací údaje, musíme pÅ™idat volbu credentials: "include", například:

fetch('http://jiny-server.com', {
  credentials: "include"
});

Nyní fetch posílá cookies pocházející z jiny-server.com spolu s požadavkem na toto sídlo.

Jestliže server souhlasí s pÅ™ijetím požadavku s pÅ™ihlaÅ¡ovacími údaji, mÄ›l by do odpovÄ›di kromÄ› hlavičky Access-Control-Allow-Origin pÅ™idat i hlavičku Access-Control-Allow-Credentials: true.

Příklad:

200 OK
Access-Control-Allow-Origin: https://javascript.info
Access-Control-Allow-Credentials: true

Prosíme vÅ¡imnÄ›te si, že Access-Control-Allow-Origin nesmí u požadavků s pÅ™ihlaÅ¡ovacími údaji obsahovat hvÄ›zdičku *. Jak zde vidíme, musí tentokrát poskytnout pÅ™esný původ. To je další bezpečnostní opatÅ™ení, které zajistí, že server opravdu ví, komu důvěřuje natolik, aby mu povolil takové požadavky.

Shrnutí

Z pohledu prohlížeče existují dva druhy požadavků jiného původu: „bezpečné“ a všechny ostatní.

„Bezpečné“ požadavky musejí splňovat následující podmínky:

• Metoda: GET, POST nebo HEAD.
• Hlavičky – můžeme nastavit jedinÄ› tyto:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type na hodnotu application/x-www-form-urlencoded, multipart/form-data nebo text/plain.

Podstatným rozdílem je, že bezpečné požadavky byly proveditelné již pÅ™ed dlouhou dobou pomocí značek <form> nebo <script>, zatímco nebezpečné nemohly prohlížeče dlouhou dobu vůbec vytvářet.

Praktický rozdíl je tedy v tom, že bezpečné požadavky se posílají rovnou a s hlavičkou Origin, zatímco pro ostatní prohlížeč vytvoří pÅ™edběžný požadavek, tzv. „preflight“, kterým žádá o povolení.

Pro bezpečné požadavky:

• → Prohlížeč posílá hlavičku Origin s původem.
• ← Pro požadavky bez pÅ™ihlaÅ¡ovacích údajů (ty se standardnÄ› neposílají) by server mÄ›l nastavit:
  • Access-Control-Allow-Origin na * nebo na stejnou hodnotu jako Origin
• ← Pro požadavky s pÅ™ihlaÅ¡ovacími údaji by server mÄ›l nastavit:
  • Access-Control-Allow-Origin na stejnou hodnotu jako Origin
  • Access-Control-Allow-Credentials na true

Navíc aby server umožnil JavaScriptu přístup k jiným hlavičkám odpovÄ›di než Cache-Control, Content-Language, Content-Type, Expires, Last-Modified nebo Pragma, mÄ›l by přísluÅ¡né hlavičky vyjmenovat v seznamu v hlavičceAccess-Control-Expose-Headers.

Pro nebezpečné požadavky je před skutečným požadavkem vydán předběžný požadavek, tzv. „preflight“:

• → Prohlížeč poÅ¡le na stejné URL požadavek OPTIONS s tÄ›mito hlavičkami:
  • Access-Control-Request-Method obsahuje požadovanou metodu.
  • Access-Control-Request-Headers obsahuje seznam nebezpečných hlaviček požadavku.
• ← Server by mÄ›l odpovÄ›dÄ›t statusem 200 a tÄ›mito hlavičkami:
  • Access-Control-Allow-Methods se seznamem povolených metod,
  • Access-Control-Allow-Headers se seznamem povolených hlaviček,
  • Access-Control-Max-Age s časem v sekundách, jak dlouho si bude povolení pamatovat.
• Pak je odeslán skutečný požadavek a aplikuje se pÅ™edchozí „bezpečné“ schéma.