SSiddiq.in
Auth · treated as a security perimeter, not a feature

The riskiest code in your app is the code that says "welcome back."

Sign-in, session refresh, MFA, password reset, session invalidation. Get one of these wrong and you've built the login page for someone else's attack. This page is the checklist we hold every auth surface against.

Audit our auth
The great debate, resolved

Session cookies vs JWTs — and when to use which.

Session cookies (HttpOnly)

Default for browser apps. Revocable server-side, immune to XSS token theft, works with CSRF protection via SameSite=Lax. If your app is 'a website with a login,' this is the right answer.

Simpler · safer · revocable

JWT (short-lived + refresh)

Mobile apps, service-to-service, cross-domain APIs. Short access (15min) + long refresh (7d), refresh stored in HttpOnly cookie. Never a raw JWT in localStorage — one XSS and it's over.

Stateless · portable · scales horizontally
The flow nobody tests until it breaks

Password reset · six things that must be true.

Tokens are single-use

Used once, invalidated. Even if the user hits back.

Tokens expire in 15 minutes

Not 24 hours. Not 'until password changed.' 15 minutes.

Response is enumeration-safe

'If that email exists, we sent a link' — same response either way.

Rate-limited by email + IP

5 requests / hour / email, 20 / hour / IP. Then a captcha.

All active sessions revoked on reset

If the account was compromised, kick every session.

Notification email to the account

You always know when a reset happened, even if you didn't ask.

The threat model we design against

Five attacks. Five defences we ship by default.

Credential stuffing
1M leaked username/password pairs, tried across sites
Rate-limit + HIBP breach-password check on signup + MFA for admin
Session fixation
Attacker sets your session cookie before login
Rotate session id on every auth-state change
CSRF
Malicious site triggers state-changing action while you're logged in
SameSite=Lax cookies + CSRF token on mutating routes
Session hijacking (XSS)
JS injection reads your token from localStorage
HttpOnly cookies · never localStorage for tokens · CSP header
OAuth callback tampering
Malicious `redirect_uri` sends the code to the attacker
Exact-match allowlist · no wildcards · state parameter always

Authentication FAQ

Session cookies (HttpOnly, SameSite=Lax, Secure) for browser apps — simpler, revocable, no token-in-localStorage class of XSS bug. JWTs when you have a mobile app or a service-to-service call where cookies don't fit. Never store a long-lived JWT in localStorage.

Account takeover vectors

Seven paths to a hijacked account — and the counter for each.

Credential stuffing
Attackers replay leaked username/password lists. Defence: rate-limit per IP + per account, MFA, HaveIBeenPwned check at signup and reset.
Phishing
Fake login page harvests creds. Defence: WebAuthn / passkeys (phish-proof), unique DKIM-signed sender, user education.
Session fixation
Attacker sets a known session cookie before login. Defence: regenerate session ID on every auth-state change.
OAuth misredirect
Malicious redirect_uri exfiltrates the code. Defence: strict allowlist of exact URIs, no wildcards, PKCE on public clients.
SIM swap → SMS OTP
Attacker ports the phone number. Defence: prefer TOTP / passkeys over SMS; require re-verification on device change.
Magic-link relay
Link forwarded or leaked from inbox. Defence: single-use, 10-minute TTL, IP + user-agent binding, in-app confirmation.
Password-reset token replay
Old reset link still valid. Defence: invalidate on first use AND on new reset request; expire in 15 minutes.

Get an auth layer you'd want reviewed.

Book an audit
Right tech, honest advice

Not sure if this is the right stack for you?

Tell us your goals — we'll recommend the right technology honestly, even if it isn't this one.

  • Personal reply from Siddiq within 24 hours
  • Honest advice — no pushy sales, no fake urgency
  • Clear next steps, timeline, and estimate

We only use your details to reply to this enquiry. Privacy.