Az URL-kódolási hiba gyakran csak szóközt tartalmazó névnél, perjeles külső azonosítónál vagy aláírt linknél jelenik meg. Az egyszerű ASCII tesztek átmennek, ezért a probléma produkcióig jut. Az ok rendszerint nem a percent encoding szabály, hanem a bizonytalan felelősség: kliens, HTTP könyvtár, proxy, framework és alkalmazás mind újra átalakíthatja az értéket.

Minden komponensnek saját szabálya van

A host, path segment, teljes path, query név, query érték és fragment nem felcserélhető. A perjel adat lehet egy szegmensben, de elválasztó a teljes útban. Az ampersand új paramétert nyit.

Egyetlen globális escape függvény kontextus nélkül nem dönthet helyesen. A builder külön komponenseket fogadjon.

A string-összefűzés hétköznapi adaton bukik el

A "?q=" + value működik egy szónál, de az A&B második paramétert hoz létre. Pathban az a/b új szegmens lesz.

Előbb a dinamikus értéket kell kódolni, majd hozzáadni a strukturális jeleket. A kész URL-t érdemes újraparsolni és ellenőrizni.

A dupla kódolás adatként kezeli a százalékot

A %20 újabb encoding után %2520. Egy decode már csak a szöveges %20-at adja, nem a szóközt. Ez akkor történik, ha a kliens kész encoded értéket ad egy SDK-nak, amely nyers szöveget vár.

A szerződés mondja meg, melyik alakot fogadja. Ránézésre nem lehet biztonságosan eldönteni, hogy egy százalékos sorozat már kódolt vagy szó szerinti adat.

Az ismételt decode nem javítás

Egyes rendszerek addig dekódolnak, amíg a string változik. Így perjel, pontszegmens vagy markup csak a security check után jelenhet meg. A router és authorization eltérő identitással dolgozik.

Minden határ egyszer dekódol a szerződés szerint. Az érvénytelen escape vagy tiltott második réteg hibát eredményez.

A plusz csak bizonyos formátumban szóköz

A form-urlencoded parser a pluszt hagyományosan szóközzé alakítja. Pathban vagy általános URL-ben lehet szó szerinti jel. Ez különösen gyakran rontja el a querybe tett szabványos Base64-et.

A Base64URL elkerüli az ütközést. Ha szabványos Base64 kötelező, az értéket pontosan percent-encode-olni kell.

Az encoded slash rétegenként mást jelenthet

A %2F-et egy proxy elutasítja, másik megőrzi, harmadik perjellé alakítja routing előtt. A backend így más szegmensszámot lát, mint az edge security check.

Tetszőleges bájtot tartalmazó azonosítóhoz jobb query, URL-safe ábécé vagy request body, mint encoded slash-ra építeni.

A duplikált paraméter policyt igényel

A ?role=user&role=admin első értékét olvashatja a WAF, utolsót a framework. Más parser tömböt készít. Ez klasszikus security mismatch.

Az API rögzítse, melyik paraméter ismételhető. A váratlan duplikátumot authorization és aláírás előtt el kell utasítani.

Az aláírt URL pontos kanonizálást kér

Más paramétersorrend, hex case, padding vagy szóközreprezentáció más signature-t ad. Signer és verifier ugyanabból a struktúrából készítsen canonical stringet.

A specifikáció rögzítse a rendezést, charsetet, ismétlést és bevont komponenseket. Ismert tesztvektorokra is szükség van.

Az escaping nem akadályozza meg az open redirectet

Egy helyesen encoded next továbbra is támadó hostjára mutathat. A szintaxis helyes, a navigációs policy rossz. Belső relatív út vagy pontos allowlist kell.

Normalizált, parselt hostot és sémát kell ellenőrizni, nem substringet. User info, backslash és IDN megtévesztheti az emberi olvasót.

A Unicode először bájtokká válik

A percent encoding bájtokon működik. Ha a kliens UTF-8-at, a szerver más charsetet használ, azonos karakter más eredményt ad. Vizuálisan azonos Unicode formák byte-wise eltérhetnek.

A szerződés UTF-8-at használjon, a doménnormalizálás pedig külön lépés legyen. Signature és lookup ugyanazt az identitást lássa.

Az HTTP kliens közvetlenül küldés előtt is módosíthat

A debug logban látott string nem feltétlenül egyezik a hálózati request targettel. A könyvtár újra escape-elhet százalékot, rendezhet paramétert vagy követhet redirectet.

Integrációs tesztben egy szerver rögzítse a tényleges raw kérést. A teljes redirect lánc minden lépését ellenőrizni kell.

Az elutasítás biztonságosabb a csendes javításnál

Hibás escape, null byte vagy tiltott többszörös reprezentáció 400-as hibát kapjon. Karakterek eldobása egy érvénytelen identitásból más, létező erőforrást készíthet.

A belső log megnevezi a komponenst és szabályt, a külső válasz nem tárja fel a routing részleteit. Kompatibilitási javítás csak mért migrációként történjen.

A tesztnek végig kell járnia az infrastruktúrát

A tesztkészlet tartalmaz szóközt, pluszt, ampersandot, egyenlőségjelet, hasht, perjelet, százalékot, Unicode-ot és duplikált paramétert. Vizsgálja a klienst, CDN-t, proxyt, routert és üzleti műveletet.

A megbízható encodingnak egyetlen tulajdonosa van. Ha minden réteg ugyanazzal a strukturált címmel dolgozik, a ritka karakter nem lesz produkciós meglepetés.

Az aláírt letöltési linknek rövid életciklus kell

Az object storage presigned URL-je gyakran hostot, pathot, lejáratot és aláírást köt össze. A query újrarendezése, dupla decode vagy hostváltó redirect érvénytelenné teheti, illetve eltérő erőforrást célozhat. A signer és a storage ugyanazt a canonical request szabályt használja.

A link scope-ja legyen szűk: konkrét objektum, művelet és rövid időablak. Logok és hibajelentések ne tárolják a teljes queryt. Lejárat után a kliens új linket kérjen, ne próbálja a régi szöveget módosítani.

A proxy log nem feltétlenül a fogadott nyers formát mutatja

Egyes szerverek már normalizált pathot naplóznak, mások raw request targetet. Hibakereséskor tudni kell, melyik mező melyik fázist ábrázolja. Ellenkező esetben úgy tűnhet, hogy a kliens rossz értéket küldött, miközben a változás a proxyban történt.

Biztonsági incidenshez mindkét nézet hasznos lehet, de a nyers URL érzékeny adatot tartalmazhat. A retention és redakció ugyanúgy része a tervezésnek, mint maga az encoding.