// SECURITY
Why is client-side authentication a security hole?
Updated 2026-08-11 · 5 min read
Because anything that runs in the browser can be changed by the user. If your app decides "is this person allowed?" in front-end code, a visitor can flip that decision, unlocking paid features or admin pages, by editing a value in developer tools. Every real permission check must happen on the server.
What it is
Authentication is "who are you"; authorization is "what are you allowed to do." Broken auth is when either check is missing, or done somewhere the user controls (the browser).
Why it matters to you
People bypass your paywall by editing one value in the console, and you keep the users but lose the revenue. In worse cases, an ordinary user reaches admin functions.
How to tell if your app has it
- Find a paid or admin-only feature.
- Open developer tools and look for a flag like isPro or isAdmin in state or local storage.
- If flipping it unlocks the feature, your access check is client-side and broken.
How it happens in AI-built apps
Hiding a button when isPro is false looks like it "gates" the feature, so AI builders stop there. But hiding the button does not protect the data or action behind it, the server still answers anyone who asks.
The fix
- Enforce every permission on the server (API route, edge function, or database policy), not in the UI.
- Treat the front-end as a convenience only; assume users can send any request they like.
- Use your auth provider’s session on the server to check both identity and role on each request.
Key takeaways
- The browser is controlled by the user; front-end checks are not security.
- Hiding a button is not gating a feature, the server must enforce it.
- Check identity and permission on the server for every sensitive request.
Frequently asked
Do I still need front-end checks?
Yes, for user experience (hiding what someone cannot use). Just never rely on them for security, the server must independently enforce the same rule.