CORS-controle

Werking van de CORS-controle

De CORS-controle is ontworpen om te evalueren of een webbrowser een specifieke cross-origin aanvraag toestaat op basis van de door jou opgegeven HTTP-responsheaders en de details van de aanvraag. Door de responsheaders te plakken en de oorsprong, methode en verzoekheaders van de beoogde aanvraag te specificeren, analyseert de tool de invoer. Je geeft hierbij ook aan of er inloggegevens worden meegestuurd. Vervolgens toont de tool of de browser de aanvraag toestaat of blokkeert, inclusief een gedetailleerde uitleg op basis van het CORS-beleid.

De tool voert deze controle volledig lokaal uit. Je kopteksten en aanvraaggegevens blijven in je browser staan. Er wordt niets geüpload naar of opgeslagen door BroBroGo. De tool neemt geen contact op met een server, leest geen externe URL's, plaatst geen cookies, controleert geen DNS of TLS en wijzigt geen serverconfiguraties.

Invoerparameters en validatie

Voor een nauwkeurige controle vereist de tool specifieke invoergegevens via de interface:

• Reactie om te controleren: Een selectie tussen "Werkelijke reactie" of "Preflight-reactie".
• HTTP-reactiekoppen: Een tekstveld waarin je de HTTP-responsheaders plakt. Bij een preflight-controle moet dit ook de statusregel bevatten. De invoer is beperkt tot maximaal 200.000 tekens.
• Oorsprong aanvragen: De exacte oorsprong (scheme, host en optionele poort) van waaruit de aanvraag wordt gedaan, bijvoorbeeld https://app.example.com. Dit moet een zuivere oorsprong of null zijn, zonder URL-pad, queryparameters of inloggegevens.
• Gevraagde methode: De HTTP-methode van de aanvraag (zoals GET, POST of OPTIONS).
• Gevraagde kopnamen: De specifieke headers die via Access-Control-Request-Headers worden aangevraagd, gescheiden door komma's of regeleinden.
• Inloggegevens opnemen: Een schakelaar die aangeeft of de aanvraag cookies of HTTP-authenticatie bevat.

Tijdens het invoeren past de tool strikte validatieregels toe. Als de invoer niet aan de specificaties voldoet, verschijnen de volgende foutmeldingen:

• Bij lege headers: "Plak de HTTP-reactiekoppen voordat u deze controleert."
• Bij overschrijding van de limiet: "Deze reactie is ongewoon groot. Houd het onder ‹max›-tekens."
• Bij een ongeldige regel: "Regel ‹line› is geen geldige HTTP-header of statusregel."
• Bij een ongeldige headernaam: "Regel ‹line› bevat een ongeldige HTTP-headernaam."
• Bij een onjuiste oorsprong: "Voer een oorsprong in met alleen een schema, host en optionele poort, zoals https://app.example.com."
• Bij een ongeldige methode: "Voer een geldig token voor de HTTP-methode in."
• Bij een door de browser verboden methode: "Browsers staan de ‹method›-methode niet toe bij het ophalen van aanvragen."
• Bij een ongeldige verzoekkop: "‹header› is geen geldige HTTP-aanvraagkopnaam."
• Bij algemene invoerproblemen: "Bevestig de gemarkeerde invoer en probeer het opnieuw."

CORS-regels en de rol van Access-Control-Allow-Origin

De header Access-Control-Allow-Origin bepaalt welke oorsprong toegang krijgt tot de bronnen. De tool controleert deze header aan de hand van de opgegeven oorsprong en de aanwezigheid van inloggegevens.

Wanneer inloggegevens zijn opgenomen, mag Access-Control-Allow-Origin nooit de wildcard * bevatten. Als dit wel het geval is, blokkeert de browser de aanvraag. Daarnaast is een door komma's gescheiden lijst met meerdere oorsprongen in deze header ongeldig binnen de CORS-specificatie.

De tool evalueert de beslissing en geeft de redenen als volgt weer:

• "Access-Control-Allow-Origin komt precies overeen met ‹origin›."
• "Access-Control-Allow-Origin staat elke oorsprong voor dit verzoek toe."
• "Access-Control-Allow-Origin ontbreekt."
• "Access-Control-Allow-Origin kan niet * zijn wanneer inloggegevens zijn opgenomen."
• "Access-Control-Allow-Origin is ‹actual›, niet ‹expected›."
• "Access-Control-Allow-Origin heeft een ongeldige waarde: ‹value›."

Omgaan met inloggegevens en Access-Control-Allow-Credentials

Als een aanvraag cookies of HTTP-authenticatie bevat, is de aanwezigheid van de header Access-Control-Allow-Credentials verplicht. Deze header moet exact de waarde true hebben.

De tool past de volgende logica toe bij het controleren van inloggegevens:

• Als de aanvraag inloggegevens bevat en de header correct is ingesteld: "Access-Control-Allow-Credentials is precies waar."
• Als de aanvraag inloggegevens bevat maar de header ontbreekt of onjuist is: "Voor een inlogverzoek is Access-Control-Allow-Credentials: TRUE vereist."
• Als er geen inloggegevens worden meegestuurd: "Inloggegevens zijn niet opgenomen, dus Access-Control-Allow-Credentials heeft geen invloed op deze beslissing."

Bovendien verliezen wildcards (*) voor toegestane methoden en headers hun speciale betekenis zodra er inloggegevens in het geding zijn. In dat geval moeten alle toegestane methoden en headers expliciet worden opgesomd.

Preflight-aanvragen, methoden en headers

Bij complexe aanvragen voert de browser eerst een preflight-aanvraag uit met de HTTP-methode OPTIONS. De server moet hierop antwoorden met een succesvolle HTTP-statuscode uit de 2xx-reeks. Als er geen HTTP-statusregel in de geplakte preflight-respons staat, is de status onbekend en wordt het resultaat als onbepaald beschouwd.

De tool controleert de preflight-status en de headers Access-Control-Allow-Methods en Access-Control-Allow-Headers met de volgende uitkomsten:

• Statuscontrole:
  • "De preflight-status ‹status› is succesvol."
  • "De preflight-status ‹status› is geen succesvolle 2xx-status."
  • "Er is geen HTTP-statusregel geplakt, dus de vereiste 2xx preflight-status kan niet worden gecontroleerd."
• Methodencontrole:
  • "De preflight maakt ‹method› mogelijk."
  • "‹method› is een CORS-methode op tafel en hoeft niet in Access-Control-Allow-Methods te verschijnen."
  • "Access-Control-Allow-Methods staat ‹method› niet toe."
• Headerscontrole:
  • "Geen aangevraagde kopnamen hebben preflight-goedkeuring nodig."
  • "De preflight staat de gevraagde kopnamen toe: ‹headers›."
  • "Access-Control-Allow-Headers: * behandelt deze namen voor een verzoek zonder inloggegevens: ‹headers›."
  • "Access-Control-Allow-Headers staat het volgende niet toe: ‹headers›."

Een belangrijk grensgeval is de Authorization-header. Zelfs als de server Access-Control-Allow-Headers: * retourneert, dekt dit wildcard-teken de Authorization-header niet af. Deze header moet altijd expliciet worden vermeld in de respons. Gebeurt dit niet, dan toont de tool de melding: "Authorization moet expliciet worden vermeld; Access-Control-Allow-Headers: * dekt dit niet."

Interpretatie van de browserbeslissing

Nadat de analyse is voltooid, toont de tool een van de volgende statusmeldingen onder het kopje Browserbeslissing:

Houd er rekening mee dat een positief resultaat uitsluitend betrekking heeft op de handmatig ingevoerde gegevens. Factoren zoals omleidingen, gecachte antwoorden, wijzigingen in serverregels, actieve browserextensies of de daadwerkelijke respons na een preflight kunnen de uiteindelijke werking in een live browser nog steeds beïnvloeden.

Veelgestelde vragen

Moet ik het werkelijke antwoord of het preflight-antwoord plakken?
Gebruik Actuele reactie om te controleren of de browsercode één reactie kan lezen. Gebruik Preflight-reactie voor het OPTIONS-antwoord dat een latere methode en de gevraagde kopnamen goedkeurt.

Waarom kan een jokerteken met inloggegevens mislukken?
Wanneer cookies of HTTP-authenticatie zijn opgenomen, moet de toegestane oorsprong exact overeenkomen met de verzoekende oorsprong. Wildcards voor toegestane methoden en kopteksten verliezen ook hun wildcard-betekenis.

Bewijst een passerend resultaat dat de live aanvraag zal werken?
Nee. Dit resultaat heeft alleen betrekking op het geplakte antwoord en de aanvraaggegevens die hier zijn ingevoerd. Doorverwijzingen, reacties in de cache, veranderende serverregels, browserextensies en de daadwerkelijke reactie na een preflight kunnen de uitkomst nog steeds veranderen.