Melindungi Halaman dan Data

Having a working login is only half the job. The other half is making sure that logged-out visitors can't reach private pages and that users can't touch data that isn't theirs.

This is where authentication meets authorization. A polished login form means nothing if the dashboard URL works for anyone who types it in.

Start by hiding private pages from logged-out users. A route guard checks for a session before rendering and redirects to login if none exists.

This is a UX layer, not real security — a determined user can bypass the browser. But it stops accidental access and gives a clean, expected experience.

Frontend guards can be bypassed by anyone calling your API directly. The only protection that counts runs on the server, where you re-check the session on every request.

Whenever you prompt for a protected feature, insist the check happens server-side. "Hide the button" is never the same as "reject the request."

Rather than copy the same check into every route, put it in middleware that runs first. It reads the session from the cookie or token, confirms it's valid, and attaches the user to the request.

Routes downstream can then trust that a user exists. Centralizing the check means one place to fix if something's wrong.

Being logged in isn't permission to see everything. A user should only read and edit their own records. This ownership check is authorization.

A classic flaw: an endpoint loads a record by ID without checking it belongs to the requester. Anyone can then read others' data by changing the ID. Always verify ownership.

Some apps need more than "owner." An admin might manage all users; an editor might publish content. Roles group these permissions so checks stay simple.

Store the role on the user record and check it where needed. Keep roles coarse at first — over-engineering permissions early slows you down without benefit.

Some providers, like Supabase, let you enforce access rules right in the database with row-level security. A policy says "a user can only select rows where the owner matches their ID."

This is powerful because even a buggy API can't leak data the database refuses to return. It's defense in depth, not a replacement for server checks.

The golden rule of protection: assume every request could be forged. IDs in the URL, fields in the body, even the user ID can be tampered with by a malicious client.

Always derive the acting user from the verified session on the server, never from a value the client sent. This single habit prevents a whole class of breaches.

Sessions expire, and when they do, a protected request fails. Without handling, the user sees a cryptic error or a blank screen.

Catch the 401, clear the local session state, and redirect to login with a friendly "please sign in again" message. Smooth expiry handling makes the app feel reliable.

Verify your protection by trying to break it. Open a private API route while logged out. Change a record ID to one you don't own. Log in as a normal user and hit an admin route.

Each attempt should be cleanly rejected. If any succeeds, you've found a hole before a real attacker does.

Good protection is layered: frontend guards for UX, server middleware for the real gate, ownership and role checks for authorization, and database policies as a last line.

No single layer is enough alone, but together they make your app safe even when one layer has a bug. Build them up deliberately as your app grows.

You learned that login alone doesn't protect anything. Frontend guards improve UX, but server middleware is the real gate, re-checking the session on every request.

You added ownership and role checks for authorization, optional database policies for defense in depth, and the rule to never trust client-supplied identity. Test like an attacker, and your auth-by-prompt app stands up to abuse.