Your Frontend Is Not a Backend

People keep pushing backend responsibilities into the frontend. Some developers/vibers are even querying the database directly from the frontend.

Blind Frontend

The frontend should be blind, not aware. It doesn't get a DATABASE_URL because it has no business knowing a database exists. It gets an API base URL and a cookie it can't read.

This confusion is very common. Even one of the newest models of Claude generated configuration with the DATABASE_CONNECTION_STRING in a Next.js Dockerfile and I said "Are you insane ? :D"

try {
  await fetch(`${backendUrl}/api/auth/logout`,
  {
    method: 'POST',
    credentials: 'include' // 👈 cookie goes there automatically
   })
} catch (e) {
  console.error('[AuthStore] Logout error:', e)
}

try {
  await fetch(`${backendUrl}/api/auth/logout`,
  {
    method: 'POST',
    credentials: 'include' // 👈 cookie goes there automatically
   })
} catch (e) {
  console.error('[AuthStore] Logout error:', e)
}

I don't care if the browser gets hacked, because the attacker has nothing to take away.

No Bearer token should be in your codebase after architectural exorcism.

Bearer Tokens— The Easiest Path

People cling to Bearer tokens because they're lazy, not because they're secure. It's "path of least resistance" architecture.

You've probably heard that cookies are more secure than localStorage. That's only half true — the security doesn't come from the cookie, it comes from the HttpOnly flag. A regular cookie that is accessible to JavaScript has the same security as saved items in localStorage.

Sure, localStorage has other problems too — it's unavailable during SSR, and legacy versions of browsers may not support it at all.

More on the HttpOnly mechanics here:

HttpOnly — Your First Line of Defense I've worked on a lot of projects over the years, and some used HttpOnly cookies for auth (access tokens, refresh…