Miksi noutoni epäonnistuu CORS-virheen vuoksi?

Palvelin, johon soitat, ei sisältänyt oikeaa Access-Control-Allow-Origin-otsikkoa lähtöpisteellesi. Joko palvelin on määritettävä sallimaan sinun, tai sinun on kutsuttava sitä samasta lähteestä (yleensä taustavälityspalvelimen kautta).

Voinko ohittaa CORS:n kehittäjänä?

Omasta koodistasi selaimessa, ei – selain pakottaa sen. Omalta palvelimeltasi (taustakoodi), kyllä, koska CORS ei koske palvelinten välisiä pyyntöjä. Yleinen kiertotapa on backend-välityspalvelin: käyttöliittymäsi kutsuu taustajärjestelmääsi; taustajärjestelmäsi kutsuu kolmannen osapuolen sovellusliittymää.

Suojaako CORS API-sovellustani?

Ei suoraan. API on tavoitettavissa CORS:stä riippumatta – selain lähettää silti pyynnön. Suoja on se, että muiden sivustojen JavaScript ei voi lukea vastauksia. Suojaa API todella käyttämällä todennusta ja valtuutusta palvelimella.

Pitäisikö minun käyttää Access-Control-Allow-Origin: *?

Vain julkisille sovellusliittymille, jotka eivät hyväksy kirjautumistietoja. Käytä evästeitä tai valtuutusotsikoita käytettäessä tiettyä alkuperää tai toista kutsuva Origin (vahvistuksen kanssa). Selaimet eivät salli jokerimerkki + kirjautumistiedot.

Miksi CORS esitarkistaa vain jotkin pyynnöt?

Yksinkertaiset pyynnöt (GET, HEAD, POST perussisältötyypeillä ja ilman mukautettuja otsikoita) ovat vapautettuja – ne vastaavat sitä, mitä HTML-lomakkeet pystyivät tekemään jo ennen CORS:n olemassaoloa. Monimutkaisissa pyynnöissä ei ole analogista HTML-muotoa, joten ne esitarkistetaan antaakseen palvelimelle mahdollisuuden hylätä ennen tilamuutoksia.

CORS selitti: Kuinka selaimet päättävät, milloin ristikkäiset pyynnöt ovat sallittuja

CORS on yksi hämmentävämmistä verkkotekniikoista, koska se kertoo selaimille, mitä se sallii – ei hyökkäysten estämistä palvelimeen. Kun ymmärrät tämän eron, säännöt ovat järkeviä. CORS antaa palvelimien myöntää valikoivasti eri lähteiden käyttöoikeuksia; saman alkuperän käytäntö on oletusarvo.

Artikkelin koko runko on englanniksi alla.

Cross-Origin Resource Sharing (CORS) on selainmekanismi, jonka avulla palvelin ilmoittaa, mitkä muut alkuperät saavat käyttää sen vastauksia. Yhdessä saman alkuperäkäytännön kanssa (selaimen oletusasetus "älä anna yhden lähteen lukea toisen vastauksia") CORS tarjoaa mekanismin valikoivaan rentoutumiseen.

Saman alkuperän käytäntö ensimmäinen

Oletusarvoisesti selaimet valvovat, että alkuperässä A toimiva JavaScript ei voi lukea vastauksia alkuperästä B. Tämä on sama käytäntö. "Alkuperä" tarkoittaa järjestelmää + isäntä + porttia; https://a.example.com ja https://b.example.com ovat eri alkuperää.

Käytäntö estää yhden sivuston JavaScriptiä lukemasta tietojasi toisella sivustolla, johon olet kirjautuneena. Ilman sitä jokainen vierailemasi sivusto voisi automaattisesti lukea yksityisen selaimesi, sähköpostisi, pankkisi, -kohteensi. Vastaa mielellään, ja hyökkääjän JS näkisi vastauksen.

Mitä CORS lisää

Monet lailliset käyttötapaukset vaativat useiden lähteiden lukemista – kirjasimia CDN:stä, API-kutsuja käyttöliittymästä eri verkkotunnuksen taustajärjestelmään, upotettuja sosiaalisen median widgetejä. CORS antaa vastaavan palvelimen nimenomaisesti sanoa "kyllä, tämä toinen alkuperä voi lukea vastaukseni".

Palvelin sisältää Access-Control-Allow-Origin-otsikon vastauksessaan. Selain tarkistaa: jos pyynnön alkuperä vastaa arvoa (tai se on jokerimerkki *), vastaus altistetaan JavaScriptille. Jos ei, selain estää JavaScriptiä lukemasta sitä. Pyyntö silti meni, palvelin edelleen vastaanotti ja käsitteli — vain JavaScript-näkyvyys on rajoitettu.

Yksinkertaiset pyynnöt vs. esitarkistetut pyynnöt

"Yksinkertaisille" pyynnöille, selaintarkistaa sisällöt, POST ja CO:n perustyypit (GET, lähetä CO:t). vastauksesta. Jos CORS ei salli, JavaScript ei voi lukea sitä.

"Monimutkaisissa" pyynnöissä (PUT, DELETE, mukautetut otsikot, JSON-sisältötyyppi) selain lähettää ensin preflight OPTIONS -pyynnön, jossa kysytään "voiko alkuperä X tehdä tämän pyynnön sinulle?" Palvelin vastaa sallituilla menetelmillä ja otsikoilla. Vain hyväksytyssä selain lähettää varsinaisen pyynnön.

// Preflight
ASETUKSET /api/users HTTP/1.1
Alkuperä: https://app.example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Valtuutus

// Palvelimen vastaus
HTTP/1.1 204 Ei sisältöä
Access-Control-Allow-Origin: https://app.example.com
Pääsy-hallinta-salli-menetelmät: DELETE, GET, POST
Access-Control-Allow-Headers: Valtuutus, Sisältö-tyyppi
Access-Control-Max-Age: 86400

Preflight estää selaimia lähettämästä monimutkaisia tilanmuutospyyntöjä palvelimille, jotka eivät odota niitä – perussuojaus jopa väärin määritettyjä palvelimia vastaan. ("tunnuksia") ei lähetetä oletusarvoisesti eri lähteiden pyynnöissä. Jotta ne voidaan sisällyttää, JavaScriptin on pyydettävä:

fetch('https://api.example.com/data', { credentials: 'include' })

Ja palvelimen on vastattava Access-Control-Allow-Credentials5 in a jokeri- ja PLZ-alkuperä1 (not: trueX) Access-Control-Allow-Origin. Tämä on yleinen gocha: Access-Control-Allow-Origin: * + valtuustiedot = mikään ei toimi.

`Yleiset CORS-väärinkäsitykset`

CORS ei ole palvelimien suojausominaisuus. Pyyntö saapuu palvelimeen CORS:stä riippumatta. Selain estää JavaScriptin reading:n vastauksesta. Palvelinten on silti todennettava ja valtuutettava.
CORS ei koske kaikkia pyyntöjä. Saman alkuperän pyynnöt eivät käynnistä CORS:ää. Palvelinten väliset pyynnöt eivät myöskään. Selainten välinen yhteys on ainoa paikka, jossa CORS elää.
Jokerimerkki * on vaarallinen yhdistettynä evästeisiin. Monet opetusohjelmat ehdottavat Access-Control-Allow-Origin: * pikakorjauksena. Julkisille sovellusliittymille ilman tunnistetietoja, hyvä. Jos kyseessä on todennus, rikki.
CORS-virheet ovat palvelinpuolen ongelmia. Kun näet CORS-virheitä selainkonsolissa, korjaus on vastaavassa palvelimessa, ei pyytävässä koodissa.

CORS vs. CORS hallitsee sitä, mitä selain altistaa JavaScriptille. CSRF (katso CSRF-artikkelimme) kertoo, lähettääkö selain pyynnön ollenkaan. CORS ei estä CSRF:ää — pyyntö voidaan lähettää ja käsitellä, vaikka JavaScript ei näe vastausta. Evästeitä käyttäville tilaa muuttaville API:ille tarvitaan edelleen CSRF-tunnisteita tai SameSite-evästeitä. CORS ei korvaa niitä. Preflight-välimuisti Preflight-vastaukset voidaan tallentaa välimuistiin Access-Control-Max-Age:n kautta. Pitkät enimmäis-iät (yli 24 tuntia) vähentävät ylimääräisiä kustannuksia – jokainen erillinen (menetelmä, URL-osoite, otsikot) yhdistelmä ei esitarkastusta uudelleen ennen voimassaolon päättymistä. Lyhyet enimmäis-ikä voi pinota huomattavan viiveen. Yleiset CORS-mallit 2026 julkisissa API:ssa: Pääsy-hallinta-Salli-alkuperä: *XPLZ44 ilman päätepisteitä autentikointi. Autentikoidut sovellusliittymät: toistaa kutsuvan Originin, jos se on sallittujen luettelossa, Access-Control-Allow-Credentials: true. XPLZ-5-API4-5-PLZ-5-52XXXa API asiakkaan määrittämät sallitut luettelot.JS SDK-toimitus: staattiset tiedostot, joissa on laaja CORS, usein julkinen API-malli.

`Usein kysytyt kysymykset`

Miksi noutoni epäonnistuu CORS-virheen vuoksi?: Palvelin, johon soitat, ei sisältänyt oikeaa Access-Control-Allow-Origin-otsikkoa lähtöpisteellesi. Joko palvelin on määritettävä sallimaan sinun, tai sinun on kutsuttava sitä samasta lähteestä (yleensä taustavälityspalvelimen kautta).
Voinko ohittaa CORS:n kehittäjänä?: Omasta koodistasi selaimessa, ei – selain pakottaa sen. Omalta palvelimeltasi (taustakoodi), kyllä, koska CORS ei koske palvelinten välisiä pyyntöjä. Yleinen kiertotapa on backend-välityspalvelin: käyttöliittymäsi kutsuu taustajärjestelmääsi; taustajärjestelmäsi kutsuu kolmannen osapuolen sovellusliittymää.
Suojaako CORS API-sovellustani?: Ei suoraan. API on tavoitettavissa CORS:stä riippumatta – selain lähettää silti pyynnön. Suoja on se, että muiden sivustojen JavaScript ei voi lukea vastauksia. Suojaa API todella käyttämällä todennusta ja valtuutusta palvelimella.
Pitäisikö minun käyttää Access-Control-Allow-Origin: *?: Vain julkisille sovellusliittymille, jotka eivät hyväksy kirjautumistietoja. Käytä evästeitä tai valtuutusotsikoita käytettäessä tiettyä alkuperää tai toista kutsuva Origin (vahvistuksen kanssa). Selaimet eivät salli jokerimerkki + kirjautumistiedot.
Miksi CORS esitarkistaa vain jotkin pyynnöt?: Yksinkertaiset pyynnöt (GET, HEAD, POST perussisältötyypeillä ja ilman mukautettuja otsikoita) ovat vapautettuja – ne vastaavat sitä, mitä HTML-lomakkeet pystyivät tekemään jo ennen CORS:n olemassaoloa. Monimutkaisissa pyynnöissä ei ole analogista HTML-muotoa, joten ne esitarkistetaan antaakseen palvelimelle mahdollisuuden hylätä ennen tilamuutoksia.