Steadybase's security posture — what's implemented, what's in progress, and what's planned.

Security Overview

Steadybase takes a transparency-first approach to security. Rather than making vague claims, we document exactly what's implemented, what gaps remain, and our roadmap to close them.

:::info Last security assessment: March 4, 2026. This page reflects the current state of the platform. :::

What's Implemented

Steadybase has completed comprehensive security hardening across 16 areas:

Authentication & Authorization

Auth middleware on all API endpoints
JWT token authentication with 24-hour expiration
Randomized invite codes (no default/guessable codes)
Role-based access: admin (full access) and viewer (read-only)
Per-user chat isolation (users can only see their own conversations)

Rate Limiting

Global rate limit: 300 requests per 15 minutes
Auth endpoint rate limit: 10 requests per 15 minutes
Prevents brute-force attacks and API abuse

Network Security

CORS restricted to allowed origins
Security headers via Helmet (X-Frame-Options, X-Content-Type-Options, HSTS, etc.)
TLS 1.2+ enforced via nginx
WebSocket connections require authentication

Data Protection

Audit logging for security-relevant operations
Prompt injection defense in AI interactions
Nginx blocks access to .git, .env, and sensitive paths
File permissions set to 600 on sensitive configuration files
.env.backup files removed

Infrastructure

PM2 process management for application stability
VAPI API key not exposed through REST API
Let's Encrypt TLS certificates with auto-renewal

Known Gaps (Actively Addressing)

We are transparent about current limitations:

Critical Priority

Issue	Risk	Status	Plan
Port 3000 open externally	Direct API access bypassing nginx	Known	Close with firewall rules
JWT in localStorage fallback	XSS can steal tokens	Known	Remove fallback, use httpOnly cookies only
No CSRF protection	Cross-site request forgery	Known	Add CSRF tokens
No automated backups	Data loss risk	Known	Implement daily encrypted backups
SELinux in permissive mode	Reduced OS-level protection	Known	Enable enforcing mode

High Priority

Issue	Risk	Status	Plan
No CI/CD pipeline	Manual deployment risk	Known	GitHub Actions pipeline
CloudWatch inactive	No centralized monitoring	Known	Enable CloudWatch logging
No health check endpoints	Silent failures	Known	Add `/health` monitoring
No firewall rules (iptables)	Open network surface	Known	Configure iptables

Security Architecture

Internet
    │
    ▼
┌──────────────────┐
│  Nginx (TLS 1.2+)│  ← Let's Encrypt cert
│  Security Headers │  ← Helmet
│  Path Blocking   │  ← .git, .env blocked
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Express Server  │  ← Auth middleware
│  Rate Limiting   │  ← 300/15min global
│  CORS            │  ← Restricted origins
│  Audit Logging   │  ← All security events
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Temporal Cloud  │  ← mTLS (client cert)
│  (us-west-2)     │  ← Namespace isolation
└──────────────────┘

Next Steps

See our detailed plans:

Authentication

JWT, invite codes, and planned SSO/MFA.

Data Protection

Encryption, memory isolation, and secrets management.

Infrastructure

EC2 hardening, ECS migration, and network security.

Compliance Roadmap

SOC 2 path and enterprise readiness.

Security Overview

On this page