Weak session token and cookie configuration
If your app rolled its own authentication instead of using Supabase Auth or Clerk, the security of every logged-in session comes down to how the session token is created and stored. A few common mistakes here can let an attacker forge a session or steal one from a legitimate user.
#What goes wrong
AI-generated auth code sometimes signs tokens with a hardcoded or fallback secret, a string literal instead of a real value, or stores the session token somewhere JavaScript can read it, like localStorage, instead of an HttpOnly cookie.
#Why it matters
A weak or hardcoded signing secret means anyone can forge a valid session token for any user, including an admin, without ever knowing a password. A token readable by JavaScript means a single XSS bug anywhere on the site can be used to steal every visitor's session.
#How Heimdall checks for this
Heimdall looks at how session tokens are signed and stored: whether the signing secret comes from an environment variable rather than a hardcoded fallback, and whether the session cookie is set with HttpOnly, Secure, and SameSite flags.
#How to fix it
Generate a long random secret with something like openssl rand -hex 32, store it only in an environment variable, and never fall back to a hardcoded default. Set the session cookie with HttpOnly so client-side scripts can't read it, Secure so it only travels over HTTPS, and SameSite=Lax or Strict to limit cross-site use.
Frequently asked questions
I use Supabase Auth or NextAuth. Does this check apply to me?
Why not just store the token in localStorage for convenience?
What's a reasonable session expiry?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 29 other issues in under a minute.