Protected Routes: Server Gates, Not Hidden Links
A protected route is a server-enforced gate, not a hidden link. In Next.js, middleware or server components validate sessions before HTML ships, which matters for dashboards and billing.
Why it exists
In single-page applications, every route is just a JavaScript chunk waiting to be executed. If authorization only hides a navigation link, a user can still type /admin directly into the address bar and the bundler will serve the file. Protected routes exist because the client is untrusted; the server must decide who receives the HTML and data.
The mental model
Think of a protected route as a nightclub with a bouncer at the door rather than a curtain inside the room. The bouncer checks ID before entry. In web terms, the check must happen at the network boundary before bytes cross the wire. A client-side redirect is like hanging a please do not enter sign on an unlocked door.
How it works
In the Next.js App Router, protection typically lives in middleware or inside a server component. Middleware runs at the edge, inspects the session cookie, and issues a redirect before the request reaches application code. If the guard is inside a server component, it reads the cookie using the built-in cookies helper, validates it against an auth service, and calls redirect if the session is missing or invalid. In React Router, the equivalent is a loader that runs before the component mounts; it fetches the user profile and throws a redirect if the user is anonymous. The protected payload must never ship until the gate opens.
When to use it
Use server-level route protection for any page that renders personal data, financial information, administrative controls, or paywalled content. Use client-side guards only as UX polish, such as showing a login modal instead of a blank screen, but always pair them with a server check that runs first.
When not to use it
Do not rely on conditional rendering in a client component to hide sensitive content. Do not validate tokens by parsing localStorage in the browser and trusting the result. Do not run heavy database lookups in edge middleware on every request if you can scope the check to specific route segments, because that adds cold-start latency to every matching request.
One canonical example
A SaaS application has a dashboard revenue page built in Next.js App Router. The layout file in the dashboard segment imports the cookies helper from Next.js headers, looks for a session token, and verifies it with the auth provider. If verification fails, it calls redirect to /login. Additionally, middleware uses a matcher for /dashboard/:path* to catch direct requests at the edge. When an unauthenticated user visits the URL, they receive a 307 redirect to /login and the revenue data never leaves the database.
Interview question
A SaaS team is building a revenue dashboard in Next.js App Router. They need to ensure unauthenticated users never receive sensitive HTML or data, while avoiding unnecessary edge latency. Which approach aligns with best practices?
- a.Check localStorage for a token in the root layout and conditionally render the dashboard on the client.
- b.Hide the dashboard link in the navigation and redirect unauthenticated users with a client-side useEffect hook.
- c.Use lightweight middleware to catch requests without a session cookie, then validate the token in a server component before fetching data.Correct
- d.Validate the session in edge middleware with a heavy database lookup on every /dashboard request, and render a fallback UI on the client.
Why? this is the answer
The card emphasizes that the server must gate HTML and data before it ships, and specifically warns against heavy database lookups in edge middleware due to cold-start latency. Option C matches the canonical pattern where lightweight middleware intercepts direct requests and the server component validates the session before any sensitive payload is rendered.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles