Security at LawKade
We hold ourselves to the same standards we apply to our clients. This page describes how we protect our platform, handle customer data, and respond to security issues affecting our own systems.
Authentication and access
- Email and password authentication with bcrypt hashing (cost factor 12)
- Session tokens stored in HttpOnly, Secure, SameSite=Lax cookies — not browser storage
- CSRF protection on all mutating API endpoints
- Session expiration with sliding TTL for active sessions
- Failed-login rate limiting and brute-force lockout
- Role-based access control scoped to organizational tenants
- No user can access another organization's data
Data handling
- Customer evidence stored with SHA-256 hashing and chain-of-custody documentation
- No customer evidence placed in publicly accessible storage
- Evidence downloads require authentication and generate an audit event
- Report access is authenticated and logged — no predictable public URLs
- Session tokens, API secrets, and credentials are never logged
- Database backups retained per customer data-retention agreements
Transport and headers
- All traffic served over TLS 1.2 or newer
- Strict-Transport-Security with includeSubDomains
- X-Content-Type-Options: nosniff
- X-Frame-Options: DENY
- Referrer-Policy: strict-origin-when-cross-origin
- Permissions-Policy restricting camera, microphone, geolocation, and payment
- X-Powered-By header removed
Secrets and configuration
- All secrets managed through secure environment configuration — none committed to source control
- Database credentials, session secrets, API keys, and encryption keys are rotatable
- Application fails safely if required secrets are missing at startup
- Source maps are not exposed in production builds
Found a security issue in our systems?
If you discover a security vulnerability in LawKade systems, please report it through our responsible disclosure process. We will acknowledge your report and work to address it promptly.
Read our Responsible Disclosure Policy →