Session risk scoring — bind collect to check
How browser collect and server-side check stay honest: session bind, verdict tokens, and avoiding replayed client payloads.
By AbuseGraph Team
Client signals are useful — and forgeable
Anything collected in the browser can be copied. A serious account API must bind client collect to a server check so attackers cannot replay a “clean” payload forever.
The two-call shape
- Evaluate / collect with a publishable key from the browser (or your BFF)
- Check / signal with a secret key on your auth server
AbuseGraph’s session helpers exist so the server check can reference the prior collect without trusting raw client JSON alone.
Practical rules
- Never put
sk_keys in the browser - Prefer short-lived session / verdict tokens
- Enforce on the server even if the UI already showed a hint
Read the deeper walkthrough in our two-call model post, then wire it with @palisade/server’s check client.
Further reading
Next
Put a live check on signup
Free forever — 1,000 live API checks / month. Unlimited test keys. No credit card.
Related reading
- Engineering
Why account protection belongs close to the request
Low-latency decisions, clearer ownership of data, and a path that stays under your control.
- Engineering
The two-call model: browser collects, backend decides
Why splitting client collection from server-side decisions is better for privacy, integrity, and control.
- Guides
Integrate account protection with Clerk, Auth0, Better Auth, and Firebase
One pattern for every auth stack: collect in the browser, check with a secret key in your hook, enforce the verdict before createSession / createUser.