'n VPN kan nie CORS deaktiveer nie, dit verander die reaksie

Begin deur twee dinge te skei wat gelyktydig verander het: die netwerkroete en die browser se handhawing. 'n VPN verander die uitgangsadres; dit verander nie die bladsy se oorsprong nie, want dié word uit skema, gasheer en poort opgebou. As die versoek nou slaag, het iets in die reaksie verander, of die versoek self het verander. Om uit te werk watter een, is die hele ondersoek.

CORS is 'n kopteksprotokol wat deur die browser afgedwing word, dus kan niks op die netwerkroete dit afskakel nie.

Oorsprong is nie 'n IP-adres nie

'n Oorsprong is 'n skema, 'n gasheer en 'n poort. Dit is nie die adres waarvan pakkette vertrek nie, en dit is nie die IP wat die bediener sien nie. Daarom kan 'n VPN elke waarneembare adres verander en die oorsprong identies laat. Die browser vergelyk die reaksie se Access-Control-Allow-Origin met die bladsy se oorsprong, en die uitgangsadres kom nooit in daardie vergelyking nie.

Dus doen 'n uitbreiding of 'n instaanbediener wat lyk of dit 'n CORS-fout regstel, iets anders: dit herskryf koptekste, of dit lei die versoek so dat dit nie meer kruis-oorsprong is nie. Nie een is 'n eienskap van die VPN nie.

Wat die browser werklik stuur

Vir 'n kruis-oorsprong-versoek wat nie 'n eenvoudige een is nie, stuur die browser eers 'n voorvlug OPTIONS, met die beoogde metode en koptekste. Die bediener moet antwoord met die toestemmings wat hy toelaat, en die werklike versoek volg net as daardie antwoord die reëls bevredig. 'n VPN verander die roete wat albei uitruilings dra en kan verander wat tussenliggende dienste antwoord. Dit verander nie die oorsprongstring of die voorvlugvereiste nie.

'n Opdragreël-kliënt wys gewoonlik niks daarvan nie. Dit stuur dalk nie 'n Origin-kopteks nie, dit slaan dikwels die voorvlug oor, en dit dra dalk ander geloofsbriewe. 'n Liggaam wat aan curl teruggegee word, bewys dat die bediener curl geantwoord het.

Vind die reaksie wat verander het

Vergelyk die werklike reaksie deur elke roete, nie net die statuskode nie. Kyk na die koptekste wat CORS-toestemmings dra, die inhoudstipe, enige herverwysing, en of 'n WAF of CDN-variant 'n ander bladsy opgelewer het. 'n Streeksweiering, 'n bekragtigingsherverwysing of 'n foutbladsy sonder die toestemmingskopteks misluk alles in die browser terwyl dit soos 'n CORS-fout lyk. Dit is verskille in die afleweringsroete, en dit is die ding om te dokumenteer.

Teken die reaksiekoptekste van albei roetes op en vergelyk hulle reël vir reël. As die enigste verskil die ontbrekende Access-Control-Allow-Origin op een foutbladsy is, het jy die oorsaak gevind.

Maak die diens reg, nie die handhawing nie

Wanneer die diens joune is, noem die toegelate oorspronge en versoekkenmerke eksplisiet, en lees dan die foute wat sy frontend en tussengangers produseer. As jy dit nie doen nie, stuur die dienscienaar 'n gesaniteerde vergelyking. Moet nooit koekies, magtigingskoptekste of sessie-uitvoere in daardie verslag insluit nie, want dit is die geloofsbriewe wat die beleid bestaan om te beskerm.

Vermy browseruitbreidings wat CORS deaktiveer. Hulle verander die sekuriteitsgrens terwyl hulle die reaksieverskil versteek wat verduidelik moes word, en hulle laat dieselfde fout vir elke ander gebruiker in plek.

Teken albei reaksies op, die oorsprong wat gebruik is en die roete wat gevolg is. Daardie rekord verander 'n VPN-gerug in 'n diensfout.