The fetched session-token page did not state the default token lifetime, so no figure is recorded.
Clerk provides hosted authentication with prebuilt components and SDKs. Its docs separate the publishable key for the frontend from the secret key that must stay on the server, and describe a short-lived session JWT that SDK middleware or your code verifies on every request.
Clerk answers who the user is. Whether that user may do what they are asking is your application's job, and that is where testing focuses. Routes that read the session but skip the role check. Data layers that trust a user id sent from the browser.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| Publishable vs secret key | The publishable key (pk_test_ / pk_live_) is for the frontend; the secret key (sk_test_ / sk_live_) must not be exposed through a public environment variable. Next.js uses NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY. | docs · verified 2026-09-21 |
| Session verification server-side | The session token is a short-lived JWT stored in a cookie; SDK middleware validates it automatically, or you verify it manually with authenticateRequest() or the JWKS public key. | docs · verified 2026-09-21 |
| Manual JWT checks | Manual verification must check the algorithm, signature, exp and nbf claims and the azp (authorized parties) claim; the docs recommend setting authorizedParties against CSRF. | docs · verified 2026-09-21 |
| Route protection | clerkMiddleware does not protect routes on its own; the docs advise against protecting routes in middleware and recommend checking access as close to the data as possible. createRouteMatcher() is deprecated in favour of resource-based checks. | docs · verified 2026-09-21 |
| Account lockout | New instances lock an account after 10 failed sign-in attempts (changed from 100 on July 6, 2026) for a one-hour cooldown; passwords, resets, backup codes, email and phone codes and TOTP count. | docs · verified 2026-09-21 |
Documentation home: clerk.com/docs
10 patterns in the catalogue name Clerk; the most severe are listed here across secrets and keys, data access, login and permissions, payments. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Someone who once had a user's token, on a shared computer or through a leak, keeps access after the user logs out or changes their password.
A buyer can edit the request in their browser, pay one cent for the top plan, and your app records it as a full purchase.
Anyone can type one line in the browser console to become a paying customer, and the server hands over the paid feature without checking.
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
On the Base44 app builder, undocumented registration and one-time-password endpoints accepted a non-secret app_id, so anyone could create a verified account on a private app; Wix fixed it within 24 hours.
Jul 2025 · Wiz Research · all sources
Two days after announcing a SaaS built with Cursor and no hand-written code, its founder reported subscription bypasses, maxed-out API keys and unwanted database writes; he shut the app down three days later.
Mar 2025 · Leo (Enrichlead founder) · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Bot sign-up protection
Uses CDN signals to detect likely bots at sign-up and shows an interactive CAPTCHA challenge when suspected.
Where it stops: The Native API setting opens a request path where CAPTCHA is bypassed even with bot protection enabled; custom flows must render the CAPTCHA widget themselves.
vendor docs · verified 2026-09-21
Account lockout
Tracks failed verification attempts across sign-in methods and locks the account; limits and duration are adjustable, with an indefinite option.
Where it stops: The page states the behaviour applies if enabled on your instance; minimum configurable threshold is 5 attempts.
vendor docs · verified 2026-09-21
Signed webhooks
Webhooks are delivered by Svix and signed; verify with Clerk's verifyWebhook helper using the signing secret from the dashboard.
Where it stops: The docs say to treat the payload as unsafe until you validate it; verification is the receiver's responsibility.
vendor docs · verified 2026-09-21
Server-side token verification
authenticateRequest() handles signature, expiry and authorized-party validation.
Where it stops: Only protects endpoints where it is called; the middleware reference says to check authorization in the code that reads or mutates data.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.A bad result is account A's record appearing for account B, or an edit or delete going through.
Clerk pre-launch checklist
10 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your setup and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
We confirm the secret key is server-only, that every protected route and Server Action verifies the session with the SDK, and that authorization (roles, ownership) is checked after authentication. Clerk's docs state middleware is not where routes should be protected; we test the routes directly.
A common shape: the page checks auth but the Server Action or API route it calls does not, so a direct request bypasses the page. Call the endpoint with a second user's session and see what it returns.
Clerk documents bot protection, account lockout after failed attempts, session token verification and organisation roles. Enable lockout and bot protection, then test your own authorization checks.