URL-coderingsfouten die ontwikkelaars nog steeds maken (en opgelost)

Bugs in de URL-codering zijn subtiel, hardnekkig en worden vaak tijdens de productie ontdekt. Een misplaatst %20, een dubbel gecodeerde ampersand, of een verwarde + vs space kan API-aanroepen verbreken, trackinggegevens beschadigen en beveiligingsproblemen veroorzaken. Laten we de meest voorkomende oplossen.

Test uw codering met onze URL-encoder/decoder tool - plak een willekeurige tekenreeks en bekijk onmiddellijk het gecodeerde resultaat.

encodeURI versus encodeURIComponent

JavaScript heeft twee ingebouwde coderingsfuncties, en het gebruik van de verkeerde is de grootste bron van bugs:

// FOUT: encodeURI behoudt & in querywaarden
const url = 'https://api.example.com/search?q=' + encodeURI('tom & jerry');
// Resultaat: https://api.example.com/search?q=tom%20&%20jerry
// De & blijft behouden — nu lijkt het een aparte parameter! // JUIST
const url = 'https://api.example.com/search?q=' + encodeURIComponent('tom & jerry');
// Resultaat: https://api.example.com/search?q=tom%20%26%20jerry

Vuistregel: Gebruik encodeURIComponent voor individuele waarden. Gebruik codeURI alleen als je een volledige URL hebt waarvoor alleen niet-ASCII-tekens gecodeerd zijn.

Bugs bij dubbele codering

Dubbele codering vindt plaats wanneer een reeds gecodeerde tekenreeks opnieuw wordt gecodeerd:

const naam = 'hallo wereld';
const gecodeerd = encodeURIComponent(naam); // hallo%20wereld
const verdubbeld = encodeURIComponent(gecodeerd); // hallo%2520wereld
// %25 is de codering van % zelf!

Dit gebeurt meestal wanneer:

• Een raamwerk codeert automatisch queryparameters, en u codeert ze ook vooraf
• Een URL wordt gecodeerd voordat deze wordt opgeslagen en vervolgens opnieuw gecodeerd wanneer deze wordt opgehaald
• Middleware verwerkt de URL op meerdere lagen, waarbij elke laag codering toevoegt

Detectie

Zoek naar %25 in URL's — het is bijna altijd een teken van dubbele codering. De volgorde %2520(dubbel gecodeerde ruimte) is het klassieke veelbetekenende verhaal.

De + versus% 20 verwarring

Inzendingen in HTML-formulier (application/x-www-form-urlencoded), spaties worden +. Bij standaard procentcodering (RFC 3986) worden spaties %20.

Dit is van belang omdat:

• decodeURIComponent doet niet decoderen + terug naar de ruimte - het laat het als een letterlijke waarde achter +
• Backend-frameworks kunnen al dan niet automatisch decoderen + afhankelijk van de parser
• Als uw API dit verwacht %20 maar ontvangt +, zoekopdrachten naar 'rode+auto' leveren resultaten op voor 'rode+auto' (met een letterlijk plusteken) in plaats van 'rode auto'

// Veilige decodering die zowel + als %20 verwerkt
functie safeDecodeParam(waarde) { return decodeURIComponent(waarde.vervangen(/\+/g, '%20'));
}

UTF-8 Edge-behuizingen

Niet-ASCII-tekens zoals é, ü, 日本語, en emoji moeten procentgecodeerd zijn als hun UTF-8-bytereeksen:

encodeURIComponent('café') // caf%C3%A9
encodeURIComponent('日本語') // %E6%97%A5%E6%9C%AC%E8%AA%9E
encodeURIComponent('🔒') //%F0%9F%94%92

Er ontstaan ​​problemen wanneer:

• De server verwacht Latin-1 maar ontvangt UTF-8 (mojibake – onleesbare tekens)
• Databasekolommen zijn niet ingesteld op UTF-8, waardoor tekens van meerdere bytes stilzwijgend worden afgekapt
• Logbestanden interpreteren gecodeerde tekenreeksen met de verkeerde tekenset

Valkuilen voor omleidings- en terugbel-URL's

OAuth-callbacks en omleidings-URL's zijn vooral gevoelig voor coderingsfouten:

// Een OAuth-omleiding bouwen
const redirectUri = 'https://myapp.com/callback?source=oauth';
const authUrl = `https://provider.com/auth?redirect_uri=${encodeURIComponent(redirectUri)}`;
// Correct: de volledige callback-URL (inclusief zijn eigen ?) is gecodeerd als een enkele parameterwaarde

Veel voorkomende fouten:

• Het niet coderen van de redirect_uri helemaal niet – de ? in de callback wordt de bovenliggende URL gesplitst
• Het coderen van de redirect_uri gedeeltelijk - codeert het pad maar niet de query
• Codering van de volledige verificatie-URL in plaats van alleen de parameterwaarde

Deze bugs creëren vaak open omleidingskwetsbaarheden die aanvallers misbruiken voor phishing.

Controlelijst voor foutopsporing

Wanneer een URL niet werkt zoals verwacht, controleer dan deze in de juiste volgorde:

1. Zoek naar %25— geeft dubbele codering aan
2. Controleer + versus %20– wordt er consequent met ruimtes omgegaan?
3. Inspecteer het onbewerkte verzoek— gebruik het tabblad DevTools Network van de browser om de daadwerkelijk verzonden gecodeerde URL te bekijken
4. Test met speciale tekens- poging & = ? # / in waarden om te zien of ze de URL-structuur verbreken
5. Controleer het inhoudstype— is de server die parseert als application/x-www-form-urlencoded of toepassing/json?
6. Controleer de decodering op de server— log de onbewerkte en gedecodeerde waarden aan de serverzijde

Veilige helperfuncties

// Bouw veilig een queryreeks
functie buildQueryString(params) { return Object.entries(params) .map(([sleutel, waarde]) => `${encodeURIComponent(sleutel)}=${encodeURIComponent(waarde)}` ) .join('&');
} // Gebruik URLSearchParams (moderne browsers + Node.js)
const params = nieuwe URLSearchParams({ q: 'tom & jerry', pagina: '1' });
const url = `https://api.example.com/search?${params}`;
// Correct: verwerkt de codering automatisch

Beste praktijk: Gebruik URLSearchParams of URL constructor in plaats van handmatige tekenreeksaaneenschakeling. Ze verwerken de codering standaard correct.

Gerelateerde tools en artikelen

• URL-encoder/decoder- test codering in realtime
• JWT-beveiligingsfouten- codering is ook van belang voor de verwerking van tokens
• Controlesom-mismatch-oplossing— wanneer de codering corrupte bestandshashes wijzigt