URL

To specifikationer styrer URL'er. RFC 3986 (januar 2005, STD 66) definerer den generiske URI-syntaks som skema ":" hier-part, eventuelt efterfulgt af "?" forespørgsel og "#" fragment, hvor authority-delen skrives som valgfri userinfo "@", så vært og så valgfri ":" port (afsnit 3.2). WHATWG's URL Standard er en levende specifikation af, hvad browsere faktisk gør, herunder fejltolerant parsing af backslashes, fjernelse af tabulatorer og linjeskift og usædvanlige IPv4-skrivemåder som 2130706433 eller 0x7f.1 for 127.0.0.1. Den første URL-RFC var RFC 1738 (1994), der byggede på Tim Berners-Lees arbejde med World Wide Web. I RFC 3986's terminologi er en URL en URI, der også angiver, hvordan ressourcen findes, men afsnit 1.1.3 bemærker, at skellet mellem URL og URN har ringe praktisk værdi.

Tegn uden for den ureserverede mængde procentkodes som UTF-8-bytes (afsnit 2.1), og de reserverede gen-delims og sub-delims har strukturel betydning. Normalisering (afsnit 6) gør skema og vært til små bogstaver og fjerner punktumsegmenter (afsnit 5.2.4), og relative referencer opløses i forhold til en basis-URI efter algoritmen i afsnit 5. Fragmentet sendes aldrig til serveren. Konventionen nøgle=værdi&nøgle=værdi i forespørgselsdelen, herunder + for mellemrum, stammer fra HTML's formularkodning, ikke fra RFC 3986. Internationaliserede domænenavne omsættes til ASCII-punycode-labels med præfikset xn-- (RFC 3492) efter IDNA2008 eller UTS #46, og browsere viser kun Unicode-formen, når den består kontroller for forvekslelige tegn.

De fleste phishingtricks udnytter læserens parsing snarere end computerens. I https://login.bank.dk@evil.example/ er alt før @ userinfo, og værten er evil.example; i bank.dk.evil.example er det registrerbare domæne, læst fra højre med Public Suffix List, evil.example; homografer udskifter et latinsk bogstav med et kyrillisk, der ligner. På serversiden muliggør forskelle mellem det bibliotek, der validerer en URL, og det, der henter den, omgåelse af SSRF- og open redirect-beskyttelse, som Orange Tsai demonstrerede ved Black Hat 2017; open redirects er katalogiseret som CWE-601. Tokens eller personoplysninger i forespørgselsdelen lækker via serverlogs, browserhistorik og Referer-headeren, som Referrer-Policy begrænser. Den lækage er en af grundene til, at sikkerhedsvejledningen til OAuth 2.0 fraråder implicit flow, der returnerede adgangstokens i URL'en.

Sikker håndtering betyder at parse med ét gennemprøvet bibliotek, sammenligne de parsede dele (et godkendt skema, en præcis vært) frem for at matche delstrenge eller regex, afvise javascript: og data: i links fra brugere for at forhindre XSS og validere igen efter omdirigeringer. Ingen specifikation fastsætter en maksimal længde; servere sætter deres egne grænser og svarer med 414 URI Too Long.