Tagasuri ng CORS

Pag-unawa sa Patakaran ng Cross-Origin Resource Sharing (CORS)

Ang Cross-Origin Resource Sharing o CORS ay isang mahalagang mekanismo ng seguridad na ipinapatupad ng mga web browser. Nililimitahan nito ang kakayahan ng mga script sa isang web page na gumawa ng mga kahilingan sa ibang domain o pinagmulan (origin) na iba sa pinanggalingan ng mismong script. Sa pamamagitan ng mga partikular na HTTP response header, tinutukoy ng server kung aling mga panlabas na pinagmulan ang pinahihintulutang magbasa ng mga tugon nito.

Ang Tagasuri ng CORS ay binuo upang matulungan ang mga developer na maunawaan kung papayagan ng isang web browser ang isang partikular na cross-origin request batay sa mga ibinigay na HTTP response header at mga detalye ng kahilingan. Sinusuri ng tool ang mga patakarang ito nang lokal upang malaman kung ang kahilingan ay haharangin o papayagan ng browser.

Ang Papel ng Access-Control-Allow-Origin sa CORS

Ang Access-Control-Allow-Origin ang pinakapangunahing header sa pagpapasya ng CORS. Tinutukoy nito kung aling mga pinagmulan ang pinapayagang makakuha ng data mula sa server.

Kapag sinusuri ang header na ito, maaaring lumabas ang mga sumusunod na resulta at dahilan ng desisyon:

• Ang Access-Control-Allow-Origin ay eksaktong tumutugma sa ‹origin›. Nangyayari ito kapag ang halaga ng header ay tugma sa tinukoy na humiling na pinagmulan.
• Pinapayagan ng Access-Control-Allow-Origin ang anumang pinanggalingan para sa kahilingang ito. Ito ay kapag ginamit ang wildcard (*) para sa mga kahilingang walang kredensyal.
• Nawawala ang Access-Control-Allow-Origin. Kung wala ang header na ito, awtomatikong haharangin ng browser ang pagbasa sa tugon.
• Ang Access-Control-Allow-Origin ay ‹actual›, hindi ‹expected›. Nangyayari ang pagkakaibang ito kapag ang ibinalik na pinagmulan ng server ay hindi tumutugma sa pinagmulan ng kahilingan.
• Ang Access-Control-Allow-Origin ay may di-wastong halaga: ‹value›. Halimbawa, kung ang Access-Control-Allow-Origin ay may maramihang halaga o pinaghiwalay ng kuwit, ito ay itinuturing na di-wasto.

Paano Gumagana ang Preflight Requests sa CORS

Para sa ilang partikular na kahilingan, nagpapadala muna ang browser ng isang paunang kahilingan na tinatawag na preflight request gamit ang pamamaraang OPTIONS. Ginagawa ito upang i-verify sa server kung ligtas na ipadala ang aktwal na kahilingan. Dito pumapasok ang kahalagahan ng mga header na Access-Control-Allow-Methods at Access-Control-Allow-Headers.

Mga Pamamaraan (Methods)

Sinusuri ng browser kung ang hinihiling na paraan ng HTTP ay pinahihintulutan ng server.

• Kung ang pamamaraan ay kasama sa mga pinapayagan, ipapakita ng tool na Pinahihintulutan ng preflight ang ‹method›.
• Kung ang pamamaraan ay kabilang sa mga ligtas na uri, ipapakita ang ‹method› ay isang CORS-safelisted na paraan at hindi kailangang lumabas sa Access-Control-Allow-Methods.
• Kung hindi pinapayagan ng server ang pamamaraan, ang resulta ay Hindi pinahihintulutan ng Access-Control-Allow-Methods ang ‹method›.

Mga Header (Headers)

Katulad ng mga pamamaraan, dapat ding aprubahan ng server ang mga custom na header na ipapadala sa aktwal na kahilingan.

• Kung walang espesyal na header na ipinadala, ang desisyon ay Walang hiniling na pangalan ng header ang nangangailangan ng pag-apruba bago ang paglipad.
• Kung aprubado ang mga ito, ipapakita ang Pinahihintulutan ng preflight ang hiniling na mga pangalan ng header: ‹headers›.
• Kung hindi pinahihintulutan ng server ang mga ito, ang babala ay Hindi pinahihintulutan ng Access-Control-Allow-Headers ang: ‹headers›.

Ang Epekto ng mga Kredensyal sa Patakaran ng CORS

Kapag ang isang kahilingan ay may kasamang mga kredensyal tulad ng cookies o HTTP authentication, nagiging mas mahigpit ang mga panuntunan ng CORS. Ang toggle para sa "Isama ang mga kredensyal" sa tool ay ginagamit upang isaad ang ganitong uri ng kahilingan.

Ang epekto ng mga kredensyal sa patakaran ay kinabibilangan ng mga sumusunod na panuntunan:

1. Bawal ang Wildcard sa Origin: Ang Access-Control-Allow-Origin ay hindi maaaring maging * kapag may kasamang mga kredensyal. Kung ito ay gagawin, ang desisyon ay haharangin sa ilalim ng dahilang Ang Access-Control-Allow-Origin ay hindi maaaring * kapag may kasamang mga kredensyal.
2. Pagkawala ng Kahulugan ng Wildcard: Kapag isinama ang mga kredensyal, ang mga wildcard (*) para sa mga pinapayagang pamamaraan at header ay nawawalan ng kanilang kahulugan bilang wildcard.
3. Kailangan ng Tahasang Pag-apruba: Ang header na Access-Control-Allow-Credentials ay dapat na eksaktong true. Kung hindi, ang kahilingan ay haharangin at ipapakita ang dahilang Ang isang kredensyal na kahilingan ay nangangailangan ng Access-Control-Allow-Credentials: totoo. Kung matagumpay naman, ipapakita ang Ang Access-Control-Allow-Credentials ay eksaktong totoo.
4. Walang Kredensyal: Kung hindi pinagana ang opsyong ito, ang desisyon ay hindi maaapektuhan, na ipapakita bilang Hindi kasama ang mga kredensyal, kaya hindi naaapektuhan ng Access-Control-Allow-Credentials ang desisyong ito.

Ang Gawi ng Wildcard (*) at ang Espesyal na Kaso ng Authorization

Ang paggamit ng wildcard (*) ay isang mabilis na paraan upang payagan ang lahat ng pinagmulan, pamamaraan, o header, ngunit mayroon itong mga limitasyon:

• Kung walang kredensyal na kasama, ang * ay maaaring gamitin sa Access-Control-Allow-Methods at Access-Control-Allow-Headers. Ipapakita ng tool ang Access-Control-Allow-Headers: Sinasaklaw ng * ang mga pangalang ito para sa isang kahilingan nang walang mga kredensyal: ‹headers›.
• Gayunpaman, ang Authorization header ay may espesyal na proteksyon. Kahit na mayroong Access-Control-Allow-Headers: *, ang Authorization ay dapat pa ring tahasang nakalista sa mga pinapayagang header ng server. Kung hindi ito tahasang isinama, ang magiging desisyon ay *Ang Authorization ay dapat na tahasang nakalista; Access-Control-Allow-Headers: Hindi ito saklaw ng .

Kahalagahan ng HTTP Status Codes sa Preflight Responses

Sa mga preflight request, ang HTTP status code ng tugon ay kritikal. Ang isang matagumpay na preflight check ay nangangailangan ng matagumpay na 2xx status code mula sa server.

• Kung ang tugon ay naglalaman ng wastong status line, ipapakita ang Ang preflight status ‹status› ay matagumpay.
• Kung ang status code ay hindi pasok sa 2xx range, haharangin ang kahilingan sa dahilang Ang preflight status na ‹status› ay hindi matagumpay na 2xx status.
• Kung walang kasamang HTTP status line ang naka-paste na tugon para sa preflight check, ang resulta ay magiging "indeterminate" o hindi tiyak, at ipapakita ang dahilang Walang na-paste na linya ng status ng HTTP, kaya hindi masuri ang kinakailangang status ng 2xx preflight.

Mga Limitasyon sa Pagsusuri ng Tool

Ang Tagasuri ng CORS ay isang static na analyzer. Mahalagang tandaan ang mga sumusunod na limitasyon sa pagproseso:

• Sinusuri lamang ng tool ang mga ibinigay na tugon at detalye ng kahilingan. Hindi ito nakikipag-ugnayan sa isang live na server, hindi nagbabasa ng mga URL, hindi nagtatakda ng cookies, hindi sumusuri ng DNS/TLS, at hindi nagbabago ng mga configuration ng server.
• Ang isang dumaang resulta ay nangangahulugan lamang na ang mga partikular na header na ipinasok ay wasto para sa tinukoy na kahilingan. Hindi nito ginagarantiya na ang live na kahilingan ay gagana, dahil maaari itong maapektuhan ng mga pag-redirect, mga naka-cache na tugon, mga pagbabago sa panuntunan ng server, mga extension ng browser, o ang aktwal na tugon pagkatapos ng preflight.

Pagkapribado at Pagproseso ng Data

Ang lahat ng pagsusuri ay ginagawa nang lokal. Ang iyong mga header at mga detalye ng kahilingan ay mananatili sa iyong browser. Walang na-upload o nai-save ng BroBroGo.

Mga Madalas Itanong (FAQ)

Dapat ko bang i-paste ang aktwal na tugon o ang tugon sa preflight?

Gamitin ang Aktwal na tugon upang suriin kung ang code ng browser ay makakabasa ng isang tugon. Gumamit ng tugon sa Preflight para sa tugon na OPTIONS na nag-aapruba sa ibang paraan at sa mga hinihiling nitong pangalan ng header.

Bakit maaaring mabigo ang isang wildcard na may mga kredensyal?

Kapag isinama ang cookies o HTTP authentication, dapat na eksaktong tumugma ang pinapayagang pinagmulan sa humihiling na pinagmulan. Ang mga wildcard para sa mga pinapayagang pamamaraan at header ay nawawala rin ang kanilang wildcard na kahulugan.

Pinapatunayan ba ng isang dumaan na resulta na gagana ang live na kahilingan?

Hindi. Sinasaklaw lamang ng resultang ito ang naka-paste na tugon at ang mga detalye ng kahilingang inilagay dito. Ang mga pag-redirect, mga naka-cache na tugon, pagbabago ng mga panuntunan sa server, mga extension ng browser at ang aktwal na tugon pagkatapos ng preflight ay maaari pa ring magbago ng resulta.