Logins and accounts that keep the right people in and everyone else out

AI builders like Bolt, Lovable and Replit make it easy to add sign-up and sign-in. You type a prompt, and a login page appears, wired to a service like Supabase, Clerk or Firebase. That is real progress. But a login page is only the visible part. Behind it sit decisions about who can see which data, which keys are allowed where, and what happens when someone forgets a password.

When those decisions are left on defaults, two things tend to happen. Either real users get stuck, or private data is more open than you think. Neither is obvious from the outside, because the app still looks like it works.

A working login screen tells you people can sign in. It does not tell you what they can see once they do.

Why it matters

If customers trust you with an email address, an order history or anything personal, keeping it private is part of the deal. And if signing up is how you get users, every broken verification email or failed reset is a person who quietly leaves. Good auth is both a safety issue and a growth issue.

What people miss

• Row Level Security turned off or left wide open. In Supabase, tables the browser can reach need RLS enabled and policies written. A table with RLS off, or a policy that allows everyone, can expose every row.
• Secret keys in frontend code. The Supabase service_role key, Firebase admin credentials and similar secrets bypass your rules. They belong on a server or in a server function, never in code that ships to the browser. The public “anon” or publishable key is meant for the browser; the secret one is not.
• Verification and reset emails from a default sender. Many auth providers send from a shared address with tight rate limits. Emails land in spam or stop sending once you grow. A custom sender on your domain, with SPF, DKIM and DMARC set up, fixes most of this.
• Redirect URLs still pointing at a preview. Reset and magic links often send people back to a localhost or preview address, because that is where the app was built. They need to point at your live domain.
• Roles enforced only in the interface. Hiding an admin button is not the same as blocking admin actions. The database or server has to check the role too.
• Session basics. Sign-out should actually end the session, sessions should expire on a sensible schedule, and tokens should not be copied into places like URLs or logs.
• Test accounts left behind. Demo users with simple passwords and full access are easy to forget after launch.

How AftUp handles it

On every plan, we review your login setup as part of getting your site live and keep an eye on it from there. You keep full ownership of your auth provider account and your code. We work inside the tools you already use.

• Starter includes a monthly form test, and your sign-up form can be part of it, so you know new users can still get in. Your plain-English report flags anything that looks off.
• Growth adds up to 2 hours a month of fixes. That is typically enough to enable and write RLS policies on key tables, move a secret key out of the browser, fix redirect URLs, or set up a custom email sender for verification and resets. Fixes get a response within 1 business day.
• Scale gives you up to 6 hours a month for larger work, such as adding user roles or restructuring how data is stored, plus same-day priority response and a direct line to a Clicking Awesome strategist.

If your login handles payments or anything sensitive, we will tell you plainly where the risk is and what we recommend. You can read more about the data side in our post on logins and private data.

Do it yourself

If you want to check the basics on your own, start here:

1. Find every secret key. Search your project for words like “service_role”, “secret” and “admin”. Anything that is a secret should live in server-side environment variables, not in frontend files. If one was ever exposed, rotate it in your provider’s dashboard.
2. Check RLS on each table. In Supabase, confirm RLS is enabled on every table the app reads from the browser, and read each policy in plain words. Ask: who can read this, and who can change it?
3. Sign up as a stranger. Use a fresh email address. Confirm the verification email arrives, lands in the inbox, and links to your live domain.
4. Reset a password. Do the full loop on your phone and on a laptop.
5. Try to peek. Sign in as one test user and see whether you can load another user’s data by changing an ID in the address bar or a request.
6. Clean up. Remove old test accounts and confirm sign-out really signs you out.

Most AI-built apps need a few adjustments here before they are ready for real users. Our security and backups page covers the account hygiene that sits around your login.

Not sure how your login setup measures up? Send us your URL for a free site check and we will tell you what we find.