No. A route guard in Angular, or a protected route in React or Vue, controls navigation in the browser. It is good for user experience, but it is not access control, because anyone can call your API directly. The server must authorize every request.
What a guard actually does
Angular's documentation describes route guards as functions that control whether a user can navigate to or leave a route, with common uses such as authentication and access control. That is a statement about navigation in the app. The code runs in the user's browser, and the user controls the browser.
An attacker does not need your screens. They can open developer tools, change the guard's return value, edit stored data, or skip the app and send requests to your API with a script.
Where the real check lives
OWASP's micro frontend cheat sheet states the principle in one line of its outline: authorize every request on the server. It adds that separate repositories and deployment teams do not create browser security boundaries, and that origin separation does not authorize backend requests.
| Control | Runs where | Counts as access control? |
|---|---|---|
| Route guard or protected route | Browser | No, it is a UX layer |
| Hidden menu items and disabled buttons | Browser | No |
| Server checks on each API call | Server | Yes |
| Row or object level checks for the specific record | Server | Yes |
How to test for the gap
- Log in as a low privilege user and note the API calls the app makes.
- Replay a call that an admin screen makes, using the low privilege token, with a command line tool.
- Change an identifier in the request to another user's record and see whether the server refuses.
- Call endpoints for screens your user cannot reach, to see if the server checks the role.
- Check responses: if the server returns the data and the front end merely hides it, you have a leak.
What to keep guards for
Keep them. They stop users from landing on pages that would show errors, they keep navigation tidy and they reduce accidental use. Just document that they are cosmetic from a security view, and write server tests for the same rules.
Design habits that help
Define permissions once on the server, and send the front end a list of what the user may do, so the interface follows the server's decision and not its own copy of the rules. Avoid sending data in the response that the screen does not show. Log denied requests, since a burst of them is a signal.
Try it yourself
Click through it at your own pace, or open it full screen. Look for authorization findings on endpoints, the checks a route guard cannot replace.
Safeguard's free scan at gold.safeguard.sh/scan covers dependency risk, which is separate from authorization design but part of the same review.
Quick check
Can I rely on a guard if my API is private?
A private API still receives calls from logged in users, including malicious ones. Check authorization on each request.
Should I remove guards then?
No. Keep them for usability and add server checks for security.
Sources
Last reviewed: 19 October 2026.
