CORS (Cross-Origin Resource Sharing) jelentése és működése a webfejlesztésben

A CORS (Cross-Origin Resource Sharing) egy böngészőoldali biztonsági mechanizmus, amely szabályozza, hogy egy weboldalról futó szkript hogyan férhet hozzá egy másik, eltérő eredetű erőforráshoz. Az „eredet” a protokoll (pl. HTTP vagy HTTPS), a domain (pl. example.com) és a port (pl. 80 vagy 443) kombinációja. Ha bármelyik is eltér, akkor az „cross-origin” kérésnek minősül.

A CORS lényege, hogy megakadályozza a rosszindulatú weboldalakat abban, hogy érzékeny adatokat lopjanak el egy másik weboldalról.

Enélkül a védelem nélkül egy rosszindulatú weboldal könnyedén elküldhetne AJAX kéréseket egy banki oldalnak a felhasználó nevében, és ellophatná a felhasználó adatait. A CORS lehetővé teszi a szerverek számára, hogy finomhangolják, mely eredetekből engedélyezik a kéréseket, és milyen HTTP metódusokat (GET, POST, stb.) és fejléceket.

A CORS nem akadályozza meg a szervert abban, hogy fogadjon cross-origin kéréseket, hanem a böngésző az, amely ellenőrzi a választ. Ha a szerver nem küld megfelelő CORS fejléceket, a böngésző blokkolja a választ, és a JavaScript szkript nem férhet hozzá az adatokhoz. Ez a biztonsági intézkedés megvédi a felhasználót a potenciális támadásoktól.

A CORS kihívást jelenthet a webfejlesztők számára, amikor API-kat integrálnak vagy különböző domainekről töltenek be erőforrásokat. A helytelen konfigurációk CORS hibákhoz vezethetnek, amelyek megakadályozzák a weboldal megfelelő működését. Ezért kulcsfontosságú a CORS helyes implementálása és tesztelése a webalkalmazások fejlesztése során.

Az „Origin” fogalmának részletes magyarázata: protokoll, domain, port

A CORS (Cross-Origin Resource Sharing) mechanizmus megértéséhez elengedhetetlen az „Origin” fogalmának alapos ismerete. Az „Origin” az a protokoll, domain (vagy IP cím) és port hármasa, amely azonosítja a weboldalt vagy erőforrást kezdeményező forrást.

Tehát, ha egy weboldal a https://www.pelda.hu:8080 címen fut, akkor az ő „Origin”-je https://www.pelda.hu:8080. Ha egy másik weboldal, például a http://masik.pelda.com szeretne adatot lekérni a https://www.pelda.hu:8080-ról, akkor az egy „cross-origin” kérés lesz, mert a két weboldal „Origin”-je eltérő.

Nézzük meg ezt részletesebben:

• Protokoll: A protokoll (pl. http vagy https) része az „Origin”-nek. A http://www.pelda.hu és a https://www.pelda.hu különböző „Origin”-eknek számítanak.
• Domain: A domain (pl. www.pelda.hu) szintén kulcsfontosságú. A www.pelda.hu és a masik.pelda.hu eltérő „Origin”-ek. Az aldomainek is számítanak: a blog.pelda.hu és a www.pelda.hu szintén különböző „Origin”-ek.
• Port: A portszám (pl. 8080, 80, 443) is befolyásolja az „Origin” definícióját. A https://www.pelda.hu:8080 és a https://www.pelda.hu:443, bár ugyanazon a domain-en futnak, különböző „Origin”-eknek minősülnek. Amennyiben a port nincs expliciten megadva a URL-ben (pl. https://www.pelda.hu), akkor az alapértelmezett portot (80 a http-hez, 443 a https-hez) használja a böngésző.

Az „Origin” koncepció központi szerepet játszik a webes biztonságban, mivel a böngészők ezen alapulva korlátozzák a különböző „Origin”-ek közötti interakciókat.

A böngészők alapértelmezésben tiltják a „cross-origin” kéréseket a biztonsági okokból. Ez azt jelenti, hogy egy szkript, ami a http://www.pelda.hu-n fut, nem tud közvetlenül adatot lekérni a https://api.pelda.com-ról, hacsak a szerver (https://api.pelda.com) nem teszi lehetővé ezt a CORS segítségével.

A CORS tehát egy mechanizmus, amellyel a szerverek szabályozhatják, hogy mely „Origin”-ekről engedélyezik a kéréseket. Ezzel biztosítható, hogy csak a megbízható források férjenek hozzá az adatokhoz, miközben a jogos kérések nem ütköznek akadályokba.

A böngészők szerepe a CORS szabályok betartásában

A böngészők kulcsszerepet játszanak a CORS szabályok érvényesítésében. A böngészők azok, amelyek blokkolják vagy engedélyezik a különböző eredetű erőforrásokhoz való hozzáférést, nem a szerverek. A szerverek a megfelelő HTTP válaszfejlécekkel jelzik a böngészőknek, hogy egy adott eredetű kérés engedélyezett-e vagy sem.

Amikor egy weboldal (pl. http://example.com) egy másik eredetből (pl. http://api.example.net) szeretne adatot lekérni JavaScript segítségével (pl. XMLHttpRequest vagy fetch), a böngésző először egy úgynevezett „preflight” kérést küldhet. Ez egy OPTIONS HTTP kérés, melynek célja a szerver képességeinek felmérése a CORS szempontjából. A szerver válasza meghatározza, hogy a tényleges kérés engedélyezett-e.

A böngésző a szerver válaszfejléceit vizsgálja meg, különösen az Access-Control-Allow-Origin fejlécet.

Ha az Access-Control-Allow-Origin értéke megegyezik a kérést indító oldal eredetével, vagy a * (ami bármely eredetet engedélyez), a böngésző engedélyezi a kérést. Ellenkező esetben a böngésző blokkolja a választ, és hibaüzenetet jelenít meg a JavaScript konzolon.

Fontos, hogy a böngésző csak a JavaScriptből indított kéréseket ellenőrzi. A HTML <img>, <link>, <script> vagy <iframe> tagekkel történő erőforrás-lekéréseket a böngésző általában nem korlátozza, mivel ezek nem minősülnek cross-origin adatok olvasásának a szkript oldaláról. Ugyanakkor, ha a JavaScript megpróbálja feldolgozni a <img> tagből származó képpontokat egy másik eredetből, akkor itt is belép a CORS védelem.

A böngészők különbözőképpen kezelhetik a CORS-t, de alapvető működésük megegyezik: a szerver által küldött fejlécek alapján döntenek az erőforráshoz való hozzáférés engedélyezéséről vagy tiltásáról. A fejlesztőknek ezért gondoskodniuk kell a megfelelő szerveroldali konfigurációról, hogy a böngészők a várt módon kezeljék a cross-origin kéréseket.

Same-Origin Policy (SOP): Miért van rá szükség és hogyan működik?

A Same-Origin Policy (SOP) egy kritikus biztonsági mechanizmus a webböngészőkben. Alapvető célja, hogy megvédje a felhasználók adatait a rosszindulatú weboldalak által indított, jogosulatlan kérésektől. A SOP lényege, hogy korlátozza, hogy egy adott eredetről (origin) származó JavaScript kód hogyan léphet interakcióba egy másik eredetről származó erőforrással.

Az „eredet” (origin) a protokoll (pl. HTTP vagy HTTPS), a domain (pl. example.com) és a port (pl. 80 vagy 443) hármasából áll. Két URL azonos eredetű, ha mindhárom összetevőjük megegyezik. Például, a https://www.example.com/page1.html és a https://www.example.com/page2.html azonos eredetűek, de a http://www.example.com/page1.html és a https://www.example.com/page1.html már nem, mivel a protokolljuk eltér.

A SOP megakadályozza, hogy egy weboldal JavaScript kódja közvetlenül hozzáférjen egy másik weboldal tartalmához, ha azok különböző eredetűek.

Ez a korlátozás azért szükséges, mert a böngészők gyakran tárolnak sütiket és más hitelesítő adatokat a felhasználó nevében különböző weboldalakhoz. Ha a SOP nem létezne, egy rosszindulatú weboldal JavaScript kódja könnyedén elküldhetne kéréseket a felhasználó nevében egy másik weboldalra (pl. a banki oldalára), és hozzáférhetne a bizalmas adatokhoz, vagy jogosulatlan műveleteket hajthatna végre.

A SOP nem tiltja meg teljesen a különböző eredetű erőforrások betöltését. Például, egy weboldal továbbra is beágyazhat képeket, stíluslapokat vagy szkripteket más eredetű szerverekről a <img>, <link> és <script> tagek segítségével. A korlátozás elsősorban a JavaScript-ből indított, kereszt-eredetű (cross-origin) HTTP kérésekre vonatkozik, amelyek adatokat szeretnének olvasni a válaszból.

A CORS bevezetésének okai: A SOP korlátainak feloldása és a biztonság megőrzése

A CORS (Cross-Origin Resource Sharing) egy biztonsági mechanizmus a webfejlesztésben, amely a Same-Origin Policy (SOP) korlátozásait hivatott feloldani, miközben a biztonságot megőrzi. A SOP lényege, hogy egy weboldal szkriptjei csak ugyanazon a protokollon, porton és domainen keresztül érhetnek el erőforrásokat. Ez alapvetően védelmet nyújt a kártékony szkriptek ellen, amelyek más weboldalak adatait próbálnák meg ellopni.

Azonban a SOP túlságosan szigorú lehet a modern webalkalmazások számára, amelyek gyakran különböző domainekről töltenek be adatokat. Például egy weboldal letölthet képeket egy CDN-ről, vagy adatokat egy API-tól, amelyek mind különböző eredetűek lehetnek. A CORS lehetővé teszi, hogy a szerverek szabályozzák, mely domainekről származó kérések engedélyezettek.

A CORS működése a szerveroldali válaszfejlécek beállításán alapul. A szerver a Access-Control-Allow-Origin fejléccel jelzi, hogy mely eredetekről engedélyezi a kéréseket. Ha a böngésző egy olyan kérést észlel, amely eltérő eredetű, akkor ellenőrzi ezt a fejléceket. Ha az eredet szerepel az engedélyezett listán, vagy a * (minden eredet) van beállítva, akkor a böngésző engedélyezi a kérést. Ellenkező esetben a kérés blokkolásra kerül.

A CORS célja, hogy a webes alkalmazások rugalmasabban kommunikálhassanak különböző domainek között, anélkül, hogy a biztonsági kockázatokat növelnék.

A CORS nem deaktiválja a SOP-t, hanem kiegészíti azt. Ahelyett, hogy teljesen letiltaná a cross-origin kéréseket, a CORS lehetővé teszi a szerverek számára, hogy finomhangolják, mely kérések engedélyezettek. Ez a rugalmasság elengedhetetlen a modern webfejlesztéshez, ahol a különböző szolgáltatások integrációja alapvető követelmény.

A CORS konfigurálása néha bonyolult lehet, de a helyes beállítás elengedhetetlen a webalkalmazások biztonságos és hatékony működéséhez. A nem megfelelő CORS konfiguráció biztonsági réseket eredményezhet, ezért fontos a megfelelő odafigyelés és tesztelés.

A CORS működése: Preflight kérések (OPTIONS metódus) és egyszerű kérések

A CORS (Cross-Origin Resource Sharing) egy biztonsági mechanizmus, amely a webböngészőkben van implementálva, és azt szabályozza, hogy egy weboldal, amely egy adott domainről (origin) származik, hogyan férhet hozzá erőforrásokhoz egy másik domainről. Ennek a mechanizmusnak a lényege, hogy megakadályozza a rosszindulatú weboldalakat abban, hogy érzékeny adatokat lopjanak el a felhasználóktól.

A CORS működésének megértéséhez két fő kéréstípust kell megvizsgálnunk: a preflight kéréseket (más néven előzetes kéréseket) és az egyszerű kéréseket.

Egyszerű kérések: Ezek a „legkönnyebben” teljesíthető kérések. Ahhoz, hogy egy kérés egyszerű legyen, a következő feltételeknek kell teljesülniük:

• A kérés metódusa GET, HEAD vagy POST kell, hogy legyen.
• A kézzel beállított HTTP fejlécek csak a következők lehetnek: Accept, Accept-Language, Content-Language, Content-Type.
• Ha a metódus POST, a Content-Type értéke csak a következők lehet: application/x-www-form-urlencoded, multipart/form-data, vagy text/plain.

Ha egy kérés megfelel ezeknek a feltételeknek, a böngésző egyszerűen elküldi azt a szervernek. A szerver válaszol, és a böngésző ellenőrzi a Access-Control-Allow-Origin fejlécet a válaszban. Ha a domain, ahonnan a kérés érkezett (vagy a * karakter, ami bármely domain-t jelent) szerepel ebben a fejlécben, akkor a böngésző engedélyezi a weboldalnak, hogy hozzáférjen a válasz tartalmához. Ellenkező esetben a böngésző letiltja a hozzáférést.

Preflight kérések (OPTIONS metódus): Ha egy kérés nem felel meg az egyszerű kérések követelményeinek (például egyedi HTTP fejléceket használ, vagy a PUT, DELETE metódusokat), akkor a böngésző egy előzetes kérést küld a tényleges kérés előtt. Ez az előzetes kérés egy OPTIONS HTTP metódussal történik.

Az OPTIONS kérés célja, hogy „megkérdezze” a szervert, hogy a tényleges kérés engedélyezett-e. A böngésző az OPTIONS kérésben elküldi a tényleges kérés metódusát és a használt egyedi HTTP fejléceket.

A szervernek a válaszában a következő fejléceket kell tartalmaznia:

• Access-Control-Allow-Origin: Mint az egyszerű kéréseknél, ez meghatározza, mely domainek férhetnek hozzá az erőforráshoz.
• Access-Control-Allow-Methods: Ez a fejléc felsorolja, mely HTTP metódusok engedélyezettek (pl. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Ez a fejléc felsorolja, mely egyedi HTTP fejlécek engedélyezettek a tényleges kérésben.
• Access-Control-Max-Age: Ez a fejléc megadja, hogy a böngésző mennyi ideig tárolhatja az előzetes kérés válaszát, így a következő hasonló kéréseknél nem kell újra elküldeni az OPTIONS kérést.

Ha a szerver helyesen válaszol az OPTIONS kérésre, a böngésző elküldi a tényleges kérést. Ellenkező esetben a böngésző letiltja a kérést.

Példa:

Tegyük fel, hogy egy weboldal a `https://example.com` domainről szeretne adatokat lekérni a `https://api.example.org` domainről a `PUT` metódussal, és a `X-Custom-Header` egyedi HTTP fejlécet használja. A böngésző először egy OPTIONS kérést küld a `https://api.example.org` címre. A szerver válaszolhat a következő fejlécekkel:

• Access-Control-Allow-Origin: https://example.com
• Access-Control-Allow-Methods: PUT
• Access-Control-Allow-Headers: X-Custom-Header

Ebben az esetben a böngésző engedélyezi a `PUT` kérést a `https://example.com` domainről az `X-Custom-Header` fejléc használatával.

A „Access-Control-Allow-Origin” válaszfejléc magyarázata és lehetséges értékei

A Access-Control-Allow-Origin HTTP válaszfejléc a CORS (Cross-Origin Resource Sharing) mechanizmus kulcsfontosságú eleme. Ez a fejléc határozza meg, hogy mely eredetek (origin) számára engedélyezi a szerver az erőforrásainak elérését egy böngészőből származó, más eredetű (cross-origin) kérés esetén. Más szóval, ez a fejléc adja meg a böngészőnek, hogy a szerver elfogadja-e az adott eredetből származó kérést.

Ennek a fejlécnek többféle lehetséges értéke van:

• * (csillag): Ez a legengedékenyebb beállítás. Azt jelenti, hogy bármely eredetből származó kérés engedélyezett.
  

  Ez a beállítás egyszerűsíti a fejlesztést, de fontos megjegyezni, hogy biztonsági kockázatot jelenthet, különösen ha érzékeny adatokat tartalmazó API-t szolgál ki a szerver.

• Egy konkrét eredet (pl. https://pelda.hu): Ebben az esetben csak a megadott eredetből származó kérések engedélyezettek. Ez a legbiztonságosabb beállítás, mivel pontosan meghatározza, hogy mely weboldalak férhetnek hozzá az erőforrásokhoz. Több konkrét eredetet nem lehet egyetlen Access-Control-Allow-Origin fejlécben megadni.
• null: Ez egy speciális érték, amelyet ritkán használnak. Azt jelenti, hogy az erőforrás csak olyan kérések számára érhető el, amelyek nincsenek eredettel (pl. helyi fájlokról betöltött oldalak).

A böngésző ellenőrzi a Access-Control-Allow-Origin fejléc értékét a kérés eredetével. Ha az eredet megegyezik a fejléc értékével (vagy a fejléc *-ot tartalmaz), akkor a böngésző engedélyezi a JavaScript kód számára, hogy hozzáférjen a válasz tartalmához. Ha az eredet nem egyezik meg, a böngésző blokkolja a hozzáférést, még akkor is, ha a szerver elküldte a választ. Ez a mechanizmus védi a felhasználókat a cross-site scripting (XSS) támadások ellen.

Fontos, hogy a szerver oldali konfiguráció helyesen legyen beállítva, hogy a megfelelő Access-Control-Allow-Origin fejlécet küldje vissza. Hibás konfiguráció esetén a böngésző blokkolhatja a kéréseket, ami hibákhoz vezethet a webalkalmazásban.

A Access-Control-Allow-Origin fejléc mellett léteznek más CORS-hoz kapcsolódó válaszfejlécek is, mint például a Access-Control-Allow-Methods (amely a megengedett HTTP metódusokat határozza meg) és a Access-Control-Allow-Headers (amely a megengedett kérésfejléceket adja meg). Ezek a fejlécek együtt biztosítják a CORS mechanizmus teljes funkcionalitását.

A „Access-Control-Allow-Methods” válaszfejléc: Milyen HTTP metódusok engedélyezettek?

A CORS (Cross-Origin Resource Sharing) mechanizmusban az Access-Control-Allow-Methods válaszfejléc kulcsszerepet játszik abban, hogy egy szerver pontosan meghatározza, mely HTTP metódusokat engedélyezi egy másik eredetű (cross-origin) kérés számára. Ez a fejléc a preflight kérések (OPTIONS metódus) válaszában jelenik meg.

Az Access-Control-Allow-Methods fejléc lényegében egy lista a megengedett HTTP metódusokról, mint például GET, POST, PUT, DELETE, OPTIONS.

Ha egy böngésző cross-origin kérést indít, ami nem egy egyszerű GET vagy POST kérés (például egyedi fejléceket tartalmaz, vagy más HTTP metódust használ), akkor a böngésző először egy preflight kérést küld az OPTIONS metódussal. A szerver válaszában az Access-Control-Allow-Methods fejlécben kell felsorolnia azokat a metódusokat, amiket a tényleges kérés használhat.

Például, ha a szerver csak a GET és POST metódusokat engedélyezi, akkor a válaszfejléc így nézhet ki: Access-Control-Allow-Methods: GET, POST. Ha a böngésző egy PUT kérést akar küldeni, de az nem szerepel az Access-Control-Allow-Methods listában, akkor a böngésző megtagadja a kérést, és egy CORS hibát generál.

Fontos, hogy a szerver pontosan adja meg a támogatott metódusokat. Ha egy metódus hiányzik a listából, a böngésző nem fogja engedélyezni a kérést. Ez a mechanizmus biztosítja, hogy a szerverek kontrollálják, hogy milyen típusú cross-origin kéréseket fogadnak el, növelve ezzel a webalkalmazások biztonságát.

A „Access-Control-Allow-Headers” válaszfejléc: Egyéni fejlécek engedélyezése

A CORS (Cross-Origin Resource Sharing) mechanizmus lényeges eleme a Access-Control-Allow-Headers válaszfejléc. Ez a fejléc a szerver válaszába kerül, és meghatározza, hogy a böngésző mely egyéni (nem standard) kéréseket fogadja el a cross-origin forrásból érkező kérések esetén.

Alapértelmezésben a böngészők csak bizonyos, standard HTTP fejléceket engedélyeznek a cross-origin kérésekhez. Ha egy kliens alkalmazás egyéni fejléceket (például X-Custom-Header) szeretne küldeni egy másik domainre, a szervernek ezt explicite engedélyeznie kell az Access-Control-Allow-Headers fejlécben.

Az Access-Control-Allow-Headers fejléc értéke egy vesszővel elválasztott lista azokból a fejlécekből, amelyeket a szerver elfogad.

Például:

Access-Control-Allow-Headers: Content-Type, Authorization, X-Custom-Header

Ez azt jelenti, hogy a szerver elfogadja a Content-Type, Authorization és X-Custom-Header fejléceket a cross-origin kérésekben. Ha a kliens egy olyan egyéni fejlécet küld, amely nincs felsorolva az Access-Control-Allow-Headers fejlécben, a böngésző blokkolja a kérést, és egy CORS hibát fog generálni.

A Access-Control-Allow-Headers: * használata engedélyez minden fejlécek, de biztonsági szempontból nem ajánlott, mivel ez lehetővé teszi a kliens számára, hogy bármilyen egyéni fejlécet küldjön, ami potenciális kockázatot jelenthet.

A preflight kérések (OPTIONS metódussal) során a szervernek vissza kell adnia az Access-Control-Allow-Headers fejlécet, hogy a böngésző tudja, mely fejléceket használhatja a tényleges kérésben. Ha a preflight kérés sikertelen, a tényleges kérés nem fog elindulni.

A „Access-Control-Expose-Headers” válaszfejléc: Mely fejlécek érhetőek el a kliens oldalon?

A CORS (Cross-Origin Resource Sharing) egy biztonsági mechanizmus, amely a böngészőkben van implementálva, és korlátozza a weboldalak közötti forrásközi kéréseket. Alapértelmezés szerint a böngészők csak azonos eredetű (protokoll, domain, port) kéréseket engedélyezik a JavaScript segítségével. A „Access-Control-Expose-Headers” válaszfejléc kulcsfontosságú szerepet játszik abban, hogy mely fejlécek tartalmát tegye elérhetővé a kliens oldali JavaScript számára.

Alapértelmezés szerint, amikor egy CORS kérés sikeresen lezajlik, a böngésző csak bizonyos biztonságos válaszfejléceket (pl. Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma) teszi elérhetővé a JavaScript számára. Ha a szerver más fejléceket is szeretne elérhetővé tenni, akkor azt explicit módon meg kell adnia az „Access-Control-Expose-Headers” válaszfejlécben.

Az „Access-Control-Expose-Headers” válaszfejléc egy vesszővel elválasztott lista azon fejlécek neveivel, amelyeket a böngésző engedélyez a JavaScript számára, hogy hozzáférjen.

Például, ha a szerver azt szeretné, hogy a kliens oldali kód hozzáférjen a „X-My-Custom-Header” és a „X-Request-ID” fejlécekhez, akkor a válaszban az alábbi fejlécet kell elküldenie:

Access-Control-Expose-Headers: X-My-Custom-Header, X-Request-ID

Ha az „Access-Control-Expose-Headers” fejléc nincs beállítva, vagy nem tartalmazza a kívánt fejlécek nevét, akkor a böngésző nem fogja engedélyezni a JavaScript számára, hogy hozzáférjen azokhoz. Ez azt jelenti, hogy a XMLHttpRequest.getResponseHeader() metódus null értéket fog visszaadni az adott fejlécekre.

A „Access-Control-Allow-Credentials” válaszfejléc: Cookie-k és autentikációs adatok kezelése

A Access-Control-Allow-Credentials válaszfejléc kulcsfontosságú a CORS-alapú kérések során, amikor a böngészőnek hitelesítési adatokat (pl. cookie-kat, HTTP autentikációs fejléceket) kell továbbítania a szervernek. Alapértelmezés szerint a CORS kérések nem küldenek hitelesítési adatokat.

A helyzet megváltoztatásához két dolgot kell tenni. Először is, a kliens oldalon a JavaScript kódban (pl. Fetch API vagy XMLHttpRequest) be kell állítani a credentials opciót 'include' értékre. Ez jelzi a böngészőnek, hogy küldje el a hitelesítési adatokat a kéréssel együtt.

Másodszor, a szervernek a Access-Control-Allow-Credentials fejléccel kell válaszolnia, melynek értéke true. Ez a fejléc engedélyezi a böngésző számára, hogy a válaszból származó cookie-kat tárolja, és hogy a hitelesítési információkat a válaszhoz kapcsolja.

Ha a Access-Control-Allow-Credentials értéke nincs beállítva true-ra, vagy hiányzik a válaszból, miközben a kliens hitelesítési adatokat küldött, a böngésző blokkolja a választ.

Nagyon lényeges, hogy a Access-Control-Allow-Origin fejlécet is helyesen állítsuk be. Ha a Access-Control-Allow-Credentials értéke true, akkor a Access-Control-Allow-Origin értéke nem lehet * (minden eredet engedélyezése). Ehelyett a szervernek egy konkrét eredetet (pl. https://example.com) kell megadnia.

Ennek oka a biztonság. Ha a Access-Control-Allow-Origin * lenne, és a Access-Control-Allow-Credentials true, akkor bármely weboldal hozzáférhetne a felhasználó hitelesítési adataihoz, ami súlyos biztonsági rést eredményezne. Ezért a böngészők szigorúan betartják ezt a szabályt.

Példa egy helyes konfigurációra:

• Kliens oldalon: fetch('https://api.example.com/data', { credentials: 'include' })
• Szerver oldalon: Access-Control-Allow-Origin: https://client.example.com és Access-Control-Allow-Credentials: true

A helytelen konfigurációk komoly biztonsági kockázatot jelenthetnek, ezért körültekintően kell eljárni a hitelesítési adatok CORS-on keresztüli kezelésekor.

CORS hibák gyakori okai és megoldásuk

A CORS (Cross-Origin Resource Sharing) hibák gyakoriak a webfejlesztésben, amikor egy weboldal egy másik domainről próbál erőforrást lekérni, és a böngésző ezt blokkolja biztonsági okokból. A hibák számos okból adódhatnak, de szerencsére a legtöbbjük viszonylag egyszerűen orvosolható.

Az egyik leggyakoribb ok, hogy a szerver, ahonnan az erőforrást kérjük, nem küldi vissza a megfelelő CORS fejléceket. A legfontosabb fejléc az Access-Control-Allow-Origin, ami meghatározza, hogy mely domainek férhetnek hozzá az erőforráshoz. Ha ez a fejléc hiányzik, vagy nem tartalmazza a kérést indító domain nevét, a böngésző blokkolja a kérést.

A Access-Control-Allow-Origin fejléc értéke lehet egy konkrét domain név (pl. https://example.com) vagy a * karakter, ami azt jelenti, hogy bármely domain hozzáférhet az erőforráshoz. A * használata azonban nem ajánlott éles környezetben, mert biztonsági kockázatot jelenthet.

Egy másik gyakori probléma a preflight kérésekkel kapcsolatos. Amikor egy böngésző egy „bonyolult” (non-simple) CORS kérést indít (pl. PUT, DELETE metódus, vagy nem standard fejlécek használata), először egy OPTIONS kérést küld a szervernek, hogy ellenőrizze, engedélyezett-e a kérés. Ha a szerver nem válaszol erre a preflight kérésre a megfelelő Access-Control-Allow-Methods és Access-Control-Allow-Headers fejlécekkel, a böngésző blokkolja a tényleges kérést.

A megoldások többfélék lehetnek, attól függően, hogy mi okozza a problémát:

• Állítsd be a megfelelő CORS fejléceket a szerveren. Ez a legfontosabb lépés. Győződj meg arról, hogy az Access-Control-Allow-Origin, Access-Control-Allow-Methods és Access-Control-Allow-Headers fejlécek megfelelően vannak konfigurálva.
• Használj proxy szervert. Ha nem tudod módosítani a szerver konfigurációját, használhatsz egy proxy szervert, ami hozzáadja a szükséges CORS fejléceket.
• JSONP használata. A JSONP egy régebbi technika, ami lehetővé teszi a cross-domain kéréseket, de csak GET kérésekhez használható, és biztonsági kockázatokat hordoz magában.
• Ellenőrizd a böngésző beállításait. Néha a böngésző beállításai (pl. reklámblokkolók) is okozhatnak CORS hibákat.

Példa a szerveroldali konfigurációra (például Node.js és Express használatával):

app.use((req, res, next) => {
  res.header("Access-Control-Allow-Origin", "http://your-domain.com"); // Cseréld le a saját domain nevedre
  res.header("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
  res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  next();
});

Fontos, hogy a megfelelő domain nevet add meg a Access-Control-Allow-Origin fejlécben. Ha a * karaktert használod, az kevésbé biztonságos, de bizonyos esetekben (pl. fejlesztés során) hasznos lehet.

A CORS hibák elkerülése érdekében fontos, hogy tisztában legyél a CORS működésével, és megfelelően konfiguráld a szervert.

A CORS konfigurálása szerver oldalon (példák különböző nyelveken és keretrendszerekben: Node.js, Python/Flask, PHP/Laravel, Java/Spring)

A CORS (Cross-Origin Resource Sharing) egy böngésző biztonsági mechanizmus, amely korlátozza, hogy egy weboldal forrásából (origin) származó szkriptek hogyan férhetnek hozzá egy másik forrásból származó erőforrásokhoz. A böngészők ezt a „same-origin policy” (azonos eredet szabályzata) alapján valósítják meg, ami azt jelenti, hogy alapértelmezés szerint csak az azonos protokoll, domain és port alatt futó erőforrások között engedélyezett a kommunikáció.

Ha egy weboldal egy másik domainről (vagy akár aldomainről, portról vagy protokollról) próbál erőforrást (pl. képet, betűtípust, adatot API-n keresztül) betölteni, a böngésző alapértelmezés szerint blokkolja ezt a kérést. A CORS lehetővé teszi, hogy a szerver oldalon beállítsuk, mely domainekről engedélyezzük a kéréseket.

A CORS konfigurálása a szerver oldalon történik, HTTP válaszfejlécek beállításával. A legfontosabb válaszfejléc az Access-Control-Allow-Origin. Ennek az értékének meg kell egyeznie a kérést indító oldal eredetével (pl. https://pelda.hu), vagy beállítható a * értékre, ami azt jelenti, hogy bármilyen eredetű kérés engedélyezett.

A Access-Control-Allow-Origin: * használata nem javasolt éles környezetben, különösen akkor, ha érzékeny adatokat szolgáltatunk, mert bárki hozzáférhet az erőforrásainkhoz.

Nézzük meg, hogyan konfigurálható a CORS különböző nyelveken és keretrendszerekben:

Node.js

Node.js-ben a cors npm csomag a legelterjedtebb megoldás a CORS kezelésére. Példa:

const express = require('express');
const cors = require('cors');
const app = express();

app.use(cors()); // Minden eredetről engedélyezi a kéréseket

// Vagy specifikus eredetek engedélyezése:
// const corsOptions = {
//   origin: 'https://pelda.hu'
// };
// app.use(cors(corsOptions));

app.get('/api/data', (req, res) => {
  res.json({ message: 'Sikeres API válasz!' });
});

app.listen(3000, () => {
  console.log('A szerver fut a 3000-es porton.');
});

Python/Flask

Flask esetében a Flask-CORS kiterjesztés használható a CORS beállítására:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app) # Minden eredetről engedélyezi a kéréseket

# Vagy specifikus eredetek engedélyezése:
# CORS(app, resources={r"/api/*": {"origins": "https://pelda.hu"}})

@app.route("/api/data")
def hello_world():
    return {"message": "Sikeres API válasz!"}

if __name__ == '__main__':
    app.run(debug=True)

PHP/Laravel

Laravelben a CORS konfigurációja a config/cors.php fájlban történik. Ezen kívül használhatjuk a fruitcake/laravel-cors csomagot is.

Példa (config/cors.php):

return [
    'paths' => ['api/*'],
    'allowed_methods' => ['*'],
    'allowed_origins' => ['*'], // Nem ajánlott éles környezetben
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => [],
    'max_age' => 0,
    'supports_credentials' => false,
];

A fruitcake/laravel-cors csomag használata esetén egy middleware-t kell regisztrálni a kernelben (app/Http/Kernel.php):

protected $middleware = [
    // ...
    \Fruitcake\Cors\HandleCors::class,
];

Java/Spring

Spring Boot-ban a CORS konfigurációja többféleképpen is megoldható. Egyik lehetőség, hogy a @CrossOrigin annotációt használjuk a controllerekben vagy metódusokban:

import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@CrossOrigin(origins = "https://pelda.hu") //Specifikus eredet engedélyezése
public class MyController {

    @GetMapping("/api/data")
    public String getData() {
        return "Sikeres API válasz!";
    }
}

Egy másik lehetőség a globális CORS konfiguráció létrehozása egy WebMvcConfigurer segítségével:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOrigins("https://pelda.hu")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

Fontos megérteni a Access-Control-Allow-Methods és Access-Control-Allow-Headers válaszfejlécek szerepét is. Az Access-Control-Allow-Methods azt adja meg, hogy mely HTTP metódusok (pl. GET, POST, PUT, DELETE) engedélyezettek a kérésekhez. Az Access-Control-Allow-Headers pedig azt, hogy mely kérésfejlécek használata engedélyezett.

A Access-Control-Allow-Credentials válaszfejléc azt jelzi, hogy a böngészőnek engedélyeznie kell-e a hitelesítő adatok (pl. sütik, hitelesítési fejlécek) küldését a szerver felé. Ehhez a kérés indításakor a withCredentials flag-et be kell állítani true értékre.

A CORS előkérés (preflight request) egy OPTIONS metódussal küldött kérés, amelyet a böngésző automatikusan küld el, ha a tényleges kérés nem egyszerű kérés (pl. ha nem GET, HEAD vagy POST metódust használ, vagy ha egyedi kérésfejléceket tartalmaz). A szervernek a preflight kérésre is helyesen kell válaszolnia, beleértve a megfelelő Access-Control-Allow-Origin, Access-Control-Allow-Methods és Access-Control-Allow-Headers fejléceket.

CORS proxy szerverek: Mikor és miért lehet szükség rájuk?

A CORS (Cross-Origin Resource Sharing) egy böngésző biztonsági mechanizmus, ami korlátozza a weboldalak azon képességét, hogy más domainekből származó erőforrásokat (pl. képeket, adatokat) kérjenek le. Néha azonban szükségessé válik ezeknek a korlátozásoknak az áthidalása. Ilyenkor jönnek képbe a CORS proxy szerverek.

Egy CORS proxy szerver lényegében egy köztes szerverként működik. A böngésző ahelyett, hogy közvetlenül a cél szerverhez fordulna, először a proxy szerverhez küldi a kérést. A proxy szerver ezután továbbítja a kérést a cél szervernek, fogadja a választ, és beállítja a megfelelő CORS fejléceket, mielőtt visszaküldené a választ a böngészőnek.

Mikor lehet szükség CORS proxy szerverre?

• Ha egy API nem támogatja a CORS-t, vagy nem a mi domainünk számára.
• Ha nem tudjuk vagy nem akarjuk befolyásolni a cél szerver konfigurációját.
• Fejlesztési környezetben, amikor gyorsan szeretnénk tesztelni egy alkalmazást anélkül, hogy a CORS beállításokkal kellene bajlódnunk.

A CORS proxy szerverek használata lehetővé teszi, hogy lekérdezzünk olyan API-kat is, amelyek egyébként a CORS korlátozások miatt elérhetetlenek lennének.

Fontos azonban tudni, hogy a CORS proxy szerverek használata biztonsági kockázatokat is hordozhat magában. A proxy szerver láthatja és módosíthatja a kéréseket és válaszokat, ezért megbízható forrásból származó proxy szervert kell választani, vagy sajátot kell implementálni. A legjobb megoldás a cél szerver CORS konfigurációjának megfelelő beállítása, de a proxy szerver egy praktikus alternatíva lehet bizonyos helyzetekben.

CORS és JSONP: A különbségek és a hasonlóságok

A CORS (Cross-Origin Resource Sharing) és a JSONP (JSON with Padding) mindkettő a böngésző biztonsági korlátozásainak áthidalására szolgál, amikor egy weblap egy másik domainről próbál erőforrást (például adatot) lekérni.

A CORS egy modern megoldás, amely a szerver oldali konfigurációra támaszkodik. A szerver beállítja a Access-Control-Allow-Origin HTTP fejlécet, amely megadja, hogy mely domainek kérhetnek le tőle adatot. Ha a böngésző ezt a fejlécet látja, és az engedélyezett domainek között szerepel az aktuális oldal domainje, akkor engedélyezi a kérést.

A JSONP egy régebbi, kerülő megoldás, amely a <script> tagek működésére épít. A <script> taggel bármilyen domainről lehet JavaScript fájlt betölteni. A JSONP lényege, hogy a szerver egy JavaScript kódot ad vissza, amely egy előre meghatározott callback függvényt hív meg a lekérdezett adatokkal. Ez a callback függvény az aktuális oldalon van definiálva, így a szerver gyakorlatilag „belecsempészi” az adatot a böngészőbe.

A legfontosabb különbség, hogy a CORS a szerver oldali beállításokon alapul, míg a JSONP a kliens oldali trükközésen.

A JSONP csak GET kéréseket támogat, míg a CORS minden HTTP metódust (GET, POST, PUT, DELETE, stb.). Továbbá, a CORS biztonságosabb, mivel a szerver pontosan megadhatja, hogy mely domainek kérhetnek le tőle adatot, míg a JSONP esetében a szerver „vakon” megbízik a kliensben.

Bár a JSONP egyszerűbbnek tűnhet, a CORS a javasolt megoldás a cross-origin kérések kezelésére, mivel biztonságosabb és rugalmasabb.

CORS és a biztonság: Lehetséges támadási felületek és védekezési stratégiák

A CORS mechanizmus bár a biztonságot hivatott szolgálni, helytelen konfiguráció esetén támadási felületet jelenthet. Az egyik leggyakoribb hiba a Access-Control-Allow-Origin: * használata. Ez lényegében bárkinek engedélyezi az erőforrások elérését, ami érzékeny adatok kiszivárgásához vezethet.

Egy másik potenciális probléma a rosszul beállított Access-Control-Allow-Credentials. Ha ez engedélyezve van, de az Access-Control-Allow-Origin értéke *, az súlyos biztonsági kockázatot jelent, mivel a támadók felhasználói cookie-khoz juthatnak hozzá.

A CORS szabályok kijátszása cross-site scripting (XSS) támadásokhoz is vezethet, amennyiben a szerver hibásan kezeli a bemeneti adatokat és visszaveri azokat a válaszban.

Védekezési stratégiák:

• Soha ne használd az Access-Control-Allow-Origin: * beállítást, ha hitelesítést igénylő erőforrásokat szolgálsz ki.
• Pontosan definiáld a megengedett eredeteket az Access-Control-Allow-Origin fejlécben.
• Ellenőrizd a Origin fejlécet a kérésekben, és csak a megbízható eredeteket engedélyezd.
• Használj Content Security Policy (CSP)-t az XSS támadások elleni védelemhez.
• Alaposan teszteld a CORS konfigurációt, hogy megbizonyosodj arról, hogy megfelelően működik és nem tartalmaz biztonsági réseket.

A preflight kérések (OPTIONS) helyes kezelése is kritikus. A szervernek megfelelően kell válaszolnia ezekre a kérésekre, meghatározva a megengedett HTTP metódusokat és egyedi fejléceket. A helytelen válasz hibás CORS viselkedéshez vezethet.

Továbbá, a szerver oldali validáció elengedhetetlen. A kliens oldali CORS szabályokra hagyatkozni nem elegendő, mivel a támadók könnyen megkerülhetik azokat.

CORS és a fejlesztői eszközök: Hibakeresés és tesztelés

A CORS hibák felderítése és javítása kulcsfontosságú a webfejlesztés során. A fejlesztői eszközök (például a böngészők beépített eszközei) nélkülözhetetlenek a CORS problémák diagnosztizálásához.

A böngésző konzoljában megjelenő hibaüzenetek gyakran pontosan jelzik, hogy melyik kérés ütközik a CORS szabályokba. Ezek az üzenetek tartalmazhatják a problémás URL-t és a hiba okát is.

A leggyakoribb CORS hibaüzenet a „No ‘Access-Control-Allow-Origin’ header is present on the requested resource”, ami azt jelenti, hogy a szerver nem küldte vissza a szükséges CORS fejléceket.

A fejlesztői eszközök hálózati lapja lehetővé teszi a HTTP kérések és válaszok részletes elemzését. Ellenőrizhetjük, hogy a szerver a megfelelő Access-Control-Allow-Origin, Access-Control-Allow-Methods és Access-Control-Allow-Headers fejléceket küldi-e vissza. A Preflight kérések (OPTIONS metódussal) helyes működését is itt tudjuk ellenőrizni.

Teszteléshez használhatunk különböző online CORS ellenőrző eszközöket is, amelyek szimulálják a böngésző viselkedését és ellenőrzik a szerver válaszait. Ezek az eszközök segíthetnek a CORS konfiguráció helyességének validálásában.