​

Stanna Security Whitepaper

​

Executive Summary

​

Key Security Highlights

• Architecture: Defense-in-depth with multiple security layers
• Compliance: GDPR/CCPA compliant
• Encryption: TLS 1.3 in transit, AES-256 at rest
• Authentication: OAuth 2.0 with Google, RBAC implemented
• Monitoring: Automated security monitoring with audit logging
• Incidents: Zero security breaches since inception

​

1. Architecture & Infrastructure

​

1.1 Application Architecture

┌─────────────────────────────────────────────────────┐
│                   Client Layer                       │
│  (Browser, Mobile App, API Clients)                 │
└─────────────────┬───────────────────────────────────┘
                  │ HTTPS (TLS 1.3)
┌─────────────────▼───────────────────────────────────┐
│              Security Layer                          │
│  - WAF (Web Application Firewall)                   │
│  - DDoS Protection                                   │
│  - Rate Limiting                                     │
│  - Security Headers                                  │
└─────────────────┬───────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────┐
│           Application Layer                          │
│  - Next.js Frontend (TypeScript)                    │
│  - Node.js Backend API (TypeScript)                 │
│  - Authentication (NextAuth.js)                     │
│  - Authorization (RBAC)                             │
└─────────────────┬───────────────────────────────────┘
                  │
┌─────────────────▼───────────────────────────────────┐
│              Data Layer                              │
│  - PostgreSQL Database (Encrypted)                  │
│  - Redis Cache (Session Storage)                   │
│  - S3-compatible Storage (File Uploads)            │
└─────────────────────────────────────────────────────┘

​

1.2 Infrastructure Security

• Virtual Private Cloud (VPC) isolation
• Private subnets for databases
• Public subnets with strict firewall rules
• Network Access Control Lists (NACLs)
• Security groups with least-privilege access

• Multi-availability zone deployment
• Automated failover for high availability
• Data replication across zones
• Geographic redundancy for disaster recovery

​

2. Authentication & Authorization

​

2.1 Authentication Methods

User → Google OAuth → Stanna Backend
  ↓
JWT Token Generated (HS256 algorithm)
  ↓
Session Created (Redis)
  ↓
Access Granted

• JWT tokens with 7-day expiration
• Secure session storage in Redis
• Automatic token refresh
• Session invalidation on logout
• Concurrent session limits (configurable)

• ✅ No password storage (delegated to OAuth provider)
• ✅ Rate limiting on authentication endpoints (5 req/min)
• ✅ Audit logging of all authentication events
• ✅ Blocked consumer email domains (gmail, yahoo, etc.)
• ✅ Account lockout after failed attempts

​

2.2 Authorization Model

• Admin operations (user management, impersonation, config)
• Workspace management (settings, members, deletion)
• Client data operations (view, create, edit, delete, export)
• AI features (chat, insights, suggestions)

• Middleware-level checks on all routes
• API-level checks on all endpoints
• Real-time permission updates

​

3. Data Protection

​

3.1 Encryption

• TLS 1.3 (latest standard)
• Perfect Forward Secrecy (PFS)
• Strong cipher suites only:
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
• Certificate pinning for mobile apps
• HSTS enforced (max-age: 31536000)

• Database: AES-256 encryption
• Backups: Encrypted with separate keys
• File storage: Server-side encryption (SSE)

• Sensitive data cleared from memory after use
• No logging of sensitive data
• PII automatically redacted in logs

​

3.2 Data Isolation

-- All queries include workspace_id filter
SELECT * FROM clients
WHERE workspace_id = :current_workspace_id;

-- Row-level security enforced at database level
CREATE POLICY workspace_isolation ON clients
  USING (workspace_id = current_setting('app.current_workspace_id')::uuid);

• Database-level isolation
• API-level authorization checks
• No cross-workspace queries possible

​

3.3 Data Retention & Deletion

• Production data: Retained while account active
• Backups: 30-day rolling retention
• Audit logs: 90-day retention
• Deleted data: 30-day soft delete, then permanent

1. User initiates deletion request
2. Account marked for deletion (soft delete)
3. 30-day grace period for recovery
4. Permanent deletion from production database
5. Backup data removed within 60 days
6. Deletion confirmation email sent

• Expedited deletion available upon request
• Complete data removal within 30 days
• Deletion certificates provided

​

4. Application Security

​

4.1 Security Controls

// All inputs validated with Zod schemas
const clientSchema = z.object({
  name: z.string().min(1).max(255),
  email: z.string().email().optional(),
  mrr: z.number().nonnegative().optional(),
  healthScore: z.number().min(0).max(1).optional(),
});

• HTML: DOMPurify sanitization
• JSON: Strict typing with TypeScript
• SQL: Parameterized queries (Prisma ORM)
• URLs: URL validation and encoding

// AI-generated content sanitized before display
const sanitized = DOMPurify.sanitize(aiResponse, {
  ALLOWED_TAGS: ['h1', 'h2', 'h3', 'strong', 'em', 'span', 'br'],
  ALLOWED_ATTR: ['class'],
});

• SameSite cookies (Lax mode)
• Origin header verification
• State parameters in OAuth flow
• Token-based protection for state-changing operations

// Prisma ORM with parameterized queries
const clients = await prisma.client.findMany({
  where: { workspaceId: workspaceId }, // Safe - no string interpolation
});

​

4.2 Security Headers

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; ...
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-XSS-Protection: 1; mode=block

​

4.3 Rate Limiting

• In-memory rate limiting (Redis in production clusters)
• Client fingerprinting: IP + User-Agent hash
• 429 response with Retry-After header
• Audit logging of rate limit violations

​

5. Security Monitoring

​

5.1 Audit Logging

• Authentication events (login, logout, failures)
• Authorization events (access granted/denied)
• Admin actions (impersonation, config changes)
• Data access (views, exports)

{
  timestamp: "2025-01-30T10:30:45Z",
  eventType: "AUTH_LOGIN_SUCCESS",
  actor: { userId: "user_123", email: "[EMAIL_REDACTED]" },
  outcome: "success",
  ipAddress: "203.0.113.42"
}

• Email addresses → [EMAIL_REDACTED]
• API keys/tokens → [TOKEN_REDACTED]
• Sensitive data automatically redacted from logs

​

6. Compliance

​

6.1 GDPR Compliance

• ✅ Lawfulness, fairness, transparency
• ✅ Purpose limitation
• ✅ Data minimization
• ✅ Accuracy
• ✅ Storage limitation
• ✅ Integrity and confidentiality
• ✅ Accountability

• ✅ Right to access (Article 15)
• ✅ Right to rectification (Article 16)
• ✅ Right to erasure (Article 17)
• ✅ Right to data portability (Article 20)
• ✅ Right to object (Article 21)

• Standard DPA available for all customers
• EU Standard Contractual Clauses (SCCs)

​

6.2 CCPA Compliance

• ✅ Right to know what data is collected
• ✅ Right to delete personal information
• ✅ Right to opt-out of sale (we never sell data)
• ✅ Right to non-discrimination

• Privacy policy clearly states data collection practices
• “Do Not Sell My Info” link (though we don’t sell data)
• 45-day response time to consumer requests

​

7. Third-Party Security

​

7.1 Vendor Risk Management

1. Security certifications (SOC 2, ISO 27001)
2. Data processing agreements available
3. Encryption in transit and at rest
4. Incident response procedures
5. Regular security assessments

• Regular security reviews
• Continuous monitoring of security posture
• Data processing audits

​

7.2 API Integrations

• OAuth 2.0 for authentication
• TLS 1.2+ for all connections
• Minimal data sharing (principle of least privilege)
• Ability to revoke access instantly
• Audit logging of all integration activity

• API keys with fine-grained permissions
• Rate limiting per integration
• Webhook signature verification
• Request/response logging

​

8. Disaster Recovery & Business Continuity

​

8.1 Backup Strategy

• Database: Continuous replication + daily snapshots
• File storage: Real-time replication
• Configuration: Version-controlled in git

• Daily backups: 30 days
• Weekly backups: 90 days

• Backup integrity verified daily
• Restore testing: Monthly

​

8.2 High Availability

• Multi-zone database replication
• Load-balanced application servers
• Auto-scaling based on demand

​

9. Security Development Lifecycle

​

9.1 Secure Development

• Secure coding guidelines followed
• Code review required for all changes
• Automated security scanning in CI/CD
• Dependency vulnerability monitoring
• Regular security training for developers

• Unit tests for security-critical functions
• Integration tests for authentication/authorization
• Automated penetration testing
• Regular third-party security assessments

• Blue-green deployments (zero downtime)
• Automated rollback on errors
• Canary releases for major changes
• Environment isolation (dev/staging/prod)

​

9.2 Vulnerability Management

• Dependency scanning: Automated on every commit
• Static analysis: On every pull request
• Continuous vulnerability monitoring

• Responsible disclosure policy
• Security advisories for significant issues

​

10. Contact

​

Appendix A: Security Glossary

​

Appendix B: Compliance Mapping

​

OWASP Top 10 Coverage