ASAASA Standard
Not in Phase 1Production Foundation

Auth Hardening Essentials

Auth Safety · AUTH-23, AUTH-27 · Priority: P1

Why This Cluster Matters

Email verification and email link safety are foundational auth hardening measures that AI code generators consistently skip. Without email verification, anyone can create accounts with fake or stolen email addresses — polluting your user base and enabling abuse. Without link poisoning mitigation, password reset and magic link emails become attack vectors.

These are not advanced security measures — they're basics that every production auth system needs. AI tools skip them because they add friction to the demo experience.

Checks in This Cluster

ID Check Priority
AUTH-23 Email verification required P1
AUTH-27 Email link poisoning mitigation P2

AUTH-23: Email Verification Required

AI tools generate sign-up flows that immediately grant full access after registration — no email verification step. This means:

  • Anyone can create accounts with emails they don't own (ceo@competitor.com)
  • Bots can mass-create accounts for spam or abuse
  • Your user base fills with unverifiable accounts
  • Password reset flows send emails to addresses the "user" doesn't control

What to verify: Supabase Auth has email confirmation enabled. New users cannot access protected features until they verify their email. The app checks email_confirmed_at before granting access.

// ✅ Check email verification status
const { data: { user } } = await supabase.auth.getUser();
if (!user?.email_confirmed_at) {
  return redirect('/verify-email');
}

Supabase setting: In the Supabase dashboard → Auth → Settings, enable "Confirm email" to require verification before allowing login.

AUTH-27: Email Link Poisoning Mitigation

Password reset and magic link emails contain a redirect URL that points back to your app. If your app accepts the redirect URL from the client request, an attacker can craft a password reset request that sends the user to a malicious site — capturing the reset token.

// ❌ Attacker crafts a reset request with their domain
POST /auth/v1/recover
{
  "email": "victim@example.com",
  "redirectTo": "https://evil-site.com/capture-token"
}

The victim receives a legitimate-looking email from your app, clicks the link, and their reset token goes to the attacker.

What to verify: The redirectTo parameter is validated against an allowlist of your own domains. Supabase supports configuring allowed redirect URLs in the dashboard (Auth → URL Configuration → Redirect URLs).

Also Mentioned: AUTH-08, AUTH-20

AUTH-08 (Password hashing): If you use custom auth instead of Supabase Auth, passwords must be hashed with bcrypt/argon2 — never stored in plain text. Supabase Auth handles this automatically.

AUTH-20 (OAuth domain restriction): If you use Google/GitHub OAuth, restrict allowed domains to prevent unauthorized sign-ups from personal accounts when you only want corporate emails.

References

Related Checks

Is your app safe? Run Free Scan →