Guide

Security & Authentication

Authentication is where most security incidents begin. We implement auth systems designed to pass audits—not explain gaps.

The problem with auth today

Authentication code is often the first thing built and the last thing reviewed. Teams copy patterns from tutorials, Stack Overflow answers, or AI-generated code without understanding the security implications.

The result: session tokens stored in localStorage (vulnerable to XSS), JWTs used for everything (no revocation), permissions checked client-side (bypassable), and passwords hashed with outdated algorithms.

These mistakes used to surface in months. With AI-accelerated development, they surface in days—often in production.

Session management

For web applications, we prefer server-side sessions with secure cookies over client-side tokens. Here's what that means in practice:

Cookie configuration

• HttpOnly — cookies can't be accessed by JavaScript, preventing XSS token theft
• Secure — cookies only sent over HTTPS
• SameSite=Lax or Strict — prevents CSRF attacks without breaking normal navigation
• Reasonable expiry — 24 hours for sensitive apps, 7-30 days for low-risk with refresh

Session lifecycle

• Regenerate session ID after login — prevents session fixation attacks
• Rotate session after privilege changes — when user becomes admin, gets new session
• Proper logout — server-side session destroyed, not just cookie cleared
• Concurrent session limits — optional, but useful for high-security contexts

Server-side sessions mean you can revoke access immediately. With JWTs, you're stuck waiting for expiry or maintaining a blocklist—which defeats the purpose of stateless tokens.

Role-based access control

Permissions should be explicit, granular, and enforced server-side. We implement RBAC that scales without becoming a maintenance nightmare.

The model

• Permissions — atomic actions like documents:read, documents:write, users:invite
• Roles — named collections of permissions like editor, admin, billing
• Resources — what the permission applies to, often scoped to organization or project

Principles

• Least privilege by default — new users get minimal permissions, explicitly granted more
• Deny by default — if permission isn't explicitly granted, access is denied
• Server-side enforcement — never trust client-side permission checks
• Audit trail — log who granted what permission to whom, and when

The goal is a permission model that's easy to understand, easy to audit, and hard to misconfigure.

Token handling

Sometimes tokens are necessary: mobile apps, API access, third-party integrations. When they are, we follow these patterns:

Access tokens

• Short-lived — 15 minutes to 1 hour, depending on risk tolerance
• Minimal payload — user ID and expiry, nothing sensitive
• Signed, not encrypted — unless payload contains sensitive data

Refresh tokens

• Stored securely — HttpOnly cookie for web, secure storage for mobile
• Rotated on use — each refresh issues new refresh token, old one invalidated
• Bound to device/session — can't be used from different context
• Revocable — stored server-side with ability to invalidate

API keys

• Scoped permissions — each key has explicit, limited permissions
• Rotatable — easy to rotate without downtime
• Audited — every use logged with timestamp and action

Audit logging

Compliance frameworks (SOC 2, GDPR, HIPAA) require audit trails. Even without compliance requirements, audit logs are invaluable for debugging and incident response.

What we log

• Authentication events — login, logout, failed attempts, password changes
• Authorization decisions — access granted, access denied, permission changes
• Data access — who viewed or exported sensitive data
• Admin actions — user creation, role changes, configuration updates

Log structure

Every audit log entry includes: timestamp, actor (who), action (what), resource (on what), outcome (success/failure), and context (IP, user agent, session ID).

Logs are immutable, retained according to your compliance requirements, and queryable for incident investigation.

What you get

At the end of a security engagement, your application will have:

• Secure session configuration with proper cookie flags
• Documented RBAC model with server-side enforcement
• Token flows reviewed and hardened (if applicable)
• Audit logging active for authentication and authorization events
• Security headers configured (CSP, HSTS, X-Frame-Options, etc.)
• OWASP Top 10 risks addressed and documented

You also get documentation: how the auth system works, what decisions were made and why, and how to extend it as your application grows.

References: OWASP Top 10 (2021), OWASP Session Management Cheat Sheet, OWASP Authorization Cheat Sheet, RFC 6749 (OAuth 2.0)