Concept questionMedium~7 minProduct Features / 14 of 19

Interview question

How would you make the UI aware of user permissions without relying on the UI for security?

Build auth-aware UI with server authorization

Explains permission-aware navigation, guarded routes, server authorization, stale capabilities, and safe 401/403 handling.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would return the current user's roles or capabilities from a current-user endpoint, then use them to shape navigation, buttons, and admin links. The UI can prevent obvious dead ends, but API endpoints still authorize every protected action. If a user is unauthenticated, the app redirects to login. If authenticated but forbidden, it shows a permission-aware message instead of pretending the resource does not exist unless hiding existence is part of the security model.

Full answer below

Practice focus

Capabilities, route guards, hidden controls, API authorization, stale permissions, 401 versus 403 handling, and UX recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Full-stack candidates often know to hide buttons, but the deeper point is that UI affordances and server authorization are separate layers with different jobs.
I would return the current user's roles or capabilities from a current-user endpoint, then use them to shape navigation, buttons, and admin links. The UI can prevent obvious dead ends, but API endpoints still authorize every protected action. If a user is unauthenticated, the app redirects to login. If authenticated but forbidden, it shows a permission-aware message instead of pretending the resource does not exist unless hiding existence is part of the security model.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would handle stale capabilities. Permissions can change while a user has the app open, so a 403 from the API is always possible even if the button was visible. The UI should refresh current-user state, remove unavailable actions, and preserve user context where possible. Server-rendered pages and API route handlers need the same permission thinking as client components. Feature flags and permissions should not be mixed casually because they answer different questions.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design auth state around session expiry, refresh failure, multi-tab logout, and support diagnostics. Logs should distinguish 401 unauthenticated, 403 forbidden, and resource-not-found cases without leaking sensitive resource details. The frontend should avoid storing long-lived secrets in browser-accessible places. I would monitor denied actions, stale permission recoveries, and loops between login and protected routes. Sensitive UI routes may also need server-side guards, not only client-side redirects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating hidden buttons as security.
Showing the same message for login required and permission denied.
Ignoring stale permission changes after page load.
Storing sensitive tokens in unsafe browser-accessible state.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain 401 versus 403 behavior.
API endpoints depend on UI checks for authorization.
No recovery when capabilities change during a session.
Confuses feature flags with permissions.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in the current-user response?
How would the UI handle a surprise 403?
Which routes need server-side guards?

Continue the section

Next in Product Features: Stale Form Conflicts

Step 15 of 19

Handle stale form data and concurrency conflicts

Opening drill

Concept questionMedium~7 minProduct Features / 14 of 19

Interview question

How would you make the UI aware of user permissions without relying on the UI for security?

Build auth-aware UI with server authorization

Explains permission-aware navigation, guarded routes, server authorization, stale capabilities, and safe 401/403 handling.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Capabilities, route guards, hidden controls, API authorization, stale permissions, 401 versus 403 handling, and UX recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Full-stack candidates often know to hide buttons, but the deeper point is that UI affordances and server authorization are separate layers with different jobs.
I would return the current user's roles or capabilities from a current-user endpoint, then use them to shape navigation, buttons, and admin links. The UI can prevent obvious dead ends, but API endpoints still authorize every protected action. If a user is unauthenticated, the app redirects to login. If authenticated but forbidden, it shows a permission-aware message instead of pretending the resource does not exist unless hiding existence is part of the security model.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would handle stale capabilities. Permissions can change while a user has the app open, so a 403 from the API is always possible even if the button was visible. The UI should refresh current-user state, remove unavailable actions, and preserve user context where possible. Server-rendered pages and API route handlers need the same permission thinking as client components. Feature flags and permissions should not be mixed casually because they answer different questions.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design auth state around session expiry, refresh failure, multi-tab logout, and support diagnostics. Logs should distinguish 401 unauthenticated, 403 forbidden, and resource-not-found cases without leaking sensitive resource details. The frontend should avoid storing long-lived secrets in browser-accessible places. I would monitor denied actions, stale permission recoveries, and loops between login and protected routes. Sensitive UI routes may also need server-side guards, not only client-side redirects.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating hidden buttons as security.
Showing the same message for login required and permission denied.
Ignoring stale permission changes after page load.
Storing sensitive tokens in unsafe browser-accessible state.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain 401 versus 403 behavior.
API endpoints depend on UI checks for authorization.
No recovery when capabilities change during a session.
Confuses feature flags with permissions.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What belongs in the current-user response?
How would the UI handle a surprise 403?
Which routes need server-side guards?

Continue the section

Next in Product Features: Stale Form Conflicts

Step 15 of 19

Handle stale form data and concurrency conflicts

How would you make the UI aware of user permissions without relying on the UI for security?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you make the UI aware of user permissions without relying on the UI for security?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section