The same request, represented more than one way
Many systems allow the same underlying resource or request to be represented in more than one textual form — different encodings, alternate path notations, case variations that a downstream component treats as equivalent even though they look different as raw input. Canonicalization normalizes an input to one single, standard form before any policy decision is evaluated against it, specifically so that these different representations are all treated identically at the point a security check actually runs.
Without it, a specific and dangerous gap opens: a check evaluates one representation of a request and correctly denies it, while a different component downstream decodes an alternate representation of the exact same request into the same dangerous target — and because the check never saw that second form, or didn't recognize it as equivalent to the one it already rejected, the request proceeds anyway.
Where in the pipeline canonicalization has to happen
This makes canonicalization a question of pipeline design, not just input handling: the same canonical form has to be what both the security check and whatever ultimately acts on the request actually use, evaluated at a point genuinely before the access-control decision rather than layered on afterward as an afterthought. A canonicalization step that runs after the authorization check has already passed protects nothing — the bypass already happened at the point the check saw the wrong, unnormalized form.