Interview question
Why is an Angular route guard not an authorization boundary?
Uses guards for navigation UX while keeping permissions and data enforcement on the trusted server.
TL;DR
I use a route guard to improve navigation, such as redirecting an unauthenticated user or warning about unsaved changes. I never rely on it to protect data or privileged actions because client code can be modified or bypassed. The API validates identity and permission for every protected operation.
Angular route guards, client trust boundaries, authentication, authorization, navigation, and security.
Core answer first, then checkpoints toward a stronger answer.
Start here. This is the direct spoken answer to practice first.
A guard controls client navigation, but the user controls the browser and can call the API directly.
I use a route guard to improve navigation, such as redirecting an unauthenticated user or warning about unsaved changes. I never rely on it to protect data or privileged actions because client code can be modified or bypassed. The API validates identity and permission for every protected operation.
Optional upgrade with examples, trade-offs, and sharper phrasing.
A guard can read the current session and return a redirect tree instead of imperatively navigating, which keeps the routing decision predictable. I avoid slow or fragile network work in guards when the page can handle a loading or forbidden state more clearly. canMatch can choose whether a route configuration participates in matching, while canDeactivate supports leave confirmation. None of those replace server authorization.
Optional deeper angle for production judgment and nuance.
I align guard behavior with server outcomes so expired sessions, changed roles, deep links, and multi-tab updates do not leave the UI in a misleading state. Sensitive data is never embedded in a bundle or resolver response merely because the guard normally hides the route. Browser tests cover direct URLs and stale sessions, while API tests prove forbidden requests remain forbidden without the Angular application. The guard is a convenience layer over a trusted enforcement model.
Use these to catch weak phrasing, shallow reasoning, and risky claims.
false without giving the user a useful destination.Quick interviewer prompts inside this drill.
Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.
canMatch?Next in Angular DI, Routing, Forms & HTTP: Resolvers and navigation UX