Security Overview

Flowstate Canvas is built with security as a foundational principle, not an afterthought. Every architectural decision prioritizes protecting user data, preventing unauthorized access, and maintaining system integrity.

Security-First Architecture

The platform’s design reflects a defense-in-depth approach. Multiple layers of protection work together to create a robust security posture:

• Passwordless authentication eliminates the risks associated with password storage, reuse, and credential stuffing attacks
• Server-side API proxying keeps backend infrastructure hidden from browsers
• Secure secrets management ensures sensitive credentials never touch disk
• Role-based access control limits admin privileges to only what’s necessary
• Comprehensive audit logging tracks all privileged actions for accountability
• Content moderation with reporting and appeals protects the community
• Rate limiting prevents abuse and denial-of-service attacks

Authentication Without Passwords

Flowstate uses magic link authentication for all user logins. Users receive a single-use link via email that expires in 15 minutes. This approach:

• Eliminates password storage vulnerabilities
• Prevents credential reuse across services
• Stops brute-force password attacks
• Simplifies the user experience

Once authenticated, users receive a JWT token with a 7-day expiry. Tokens automatically renew when they have less than 2 days remaining, providing seamless long-term sessions without compromising security.

Admin authentication uses Amazon Cognito OIDC (OpenID Connect) for enterprise-grade identity management. Super admin privileges are granted automatically to whitelisted email addresses, ensuring the right people have the right access from day one.

API Communication Security

The web application never communicates directly with the backend API. All requests flow through an Astro server-side proxy:

Browser → Astro Server (/api/*) → Backend API (internal network)

This architecture provides several security benefits:

• Backend URL remains hidden from browser inspection and network analysis
• CORS complexity is eliminated since browsers only talk to the same origin
• Request validation happens server-side before reaching the backend
• Sensitive headers are stripped before forwarding (hop-by-hop headers)
• Production backend is internal-only, never exposed to the public internet

The Electron desktop app and future mobile clients use a separate RPC Gateway service that exposes only /rpc and /health endpoints. This public-facing service uses Bearer token authentication and runs independently from the internal REST API.

Secrets Management

Development and production secrets are managed through secure secrets management tooling. Secret references are stored in a template file rather than the actual values themselves.

When services start, the secrets tool resolves references and injects real values as environment variables. Secrets exist only in the process environment for the duration of the command. They’re never written to disk, never committed to version control, and never exposed in logs.

This approach:

• Centralizes secret management in a secure vault
• Prevents accidental exposure through commits or file sharing
• Enables easy rotation without code changes
• Provides audit trails for secret access
• Works seamlessly in both development and production

Production Cookie Security

All production cookies use strict security settings:

• httpOnly: Prevents JavaScript access, stopping XSS attacks from stealing tokens
• secure: Ensures cookies only transmit over HTTPS connections
• sameSite=lax: Protects against CSRF attacks while allowing normal navigation

Development environments relax these settings for local testing (HTTP instead of HTTPS), but production deployments enforce them without exception.

Rate Limiting Protection

An 8-tier rate limiting system protects against abuse and denial-of-service attacks. Limits range from 5 requests per minute for expensive operations (AI classification, CV parsing) to 300 requests per minute for high-frequency canvas updates.

Rate limits are tracked per-user for authenticated requests and per-IP for unauthenticated requests. This prevents shared-IP false positives while still protecting against malicious traffic.

All rate limiting state is stored in Redis for consistency across multiple backend instances. If Redis becomes unavailable, the system gracefully falls back to in-memory limiting to maintain protection.

Content Moderation

Users can report content for five specific reasons:

• Spam or misleading content
• Harassment or bullying
• Inappropriate or offensive material
• Copyright or intellectual property violation
• Other violations of community guidelines

Reported content is reviewed by content moderators (a dedicated admin role). Moderators can approve, reject, or escalate reports. Users whose content is moderated can appeal the decision, creating a fair and transparent process.

All moderation actions are logged in the admin audit trail for accountability.

Admin Access Control

Admin access uses a five-tier role system:

Role	Permissions
super_admin	Full platform control, user management, system configuration
admin	User management, content moderation, analytics access
developer	Technical diagnostics, feature flags, system health monitoring
content_mod	Content review, moderation actions, report handling
analyst	Read-only analytics, usage reports, metrics dashboards

Each role has the minimum permissions needed to perform its function. Super admins can promote and demote other admins, but all role changes are logged.

Admin Audit Logging

Every privileged action taken by an admin is recorded in an immutable audit log. Each entry captures:

• Action type (user_ban, content_delete, role_change, etc.)
• Target (affected user, content, or resource)
• Timestamp (when the action occurred)
• IP address (where the request originated)
• User agent (browser or client used)
• Admin identity (who performed the action)

Audit logs are queryable by date range, action type, and admin. They provide accountability and enable investigation of suspicious activity.

Environment-Based Security

Security settings adapt to the deployment environment:

Development:

• Relaxed CORS for local testing
• HTTP cookies (no secure flag)
• Verbose error messages for debugging
• Lower rate limits for easier testing

Production:

• Strict CORS with explicit allowed origins
• HTTPS-only cookies with httpOnly and secure flags
• Sanitized error messages (no stack traces)
• Full rate limiting enforcement
• Backend API is internal-only (not publicly accessible)

Environment detection happens automatically based on NODE_ENV. There’s no manual configuration needed.

Electron Desktop Security

The Electron desktop app follows security best practices:

• contextIsolation enabled: Renderer process runs in an isolated context
• nodeIntegration disabled: Renderer cannot directly access Node.js APIs
• Preload scripts: Controlled bridge between renderer and main process
• Content Security Policy: Restricts resource loading and script execution
• Bearer token authentication: Desktop app uses Authorization header, not cookies

The desktop app communicates exclusively with the RPC Gateway using Connect RPC over HTTPS. It never accesses the internal REST API.

Input Validation

Every API endpoint validates input using Zod schemas before processing. This provides:

• Type safety: Ensures data matches expected structure
• Range validation: Checks numeric bounds and string lengths
• Format validation: Verifies email addresses, URLs, and custom formats
• Injection prevention: Rejects malformed or malicious input

Validation happens at the API boundary, before data reaches business logic or the database. Invalid requests receive a 400 Bad Request response with details about what failed validation.

File Upload Protection

File uploads are restricted to specific types and sizes:

• Allowed types: JPEG, PNG, GIF, WebP only
• Maximum size: 5MB per file
• Path traversal prevention: Filenames are sanitized and validated
• Storage isolation: Files are stored in S3-compatible object storage with access controls

Uploaded files are scanned for valid image headers. Files that claim to be images but have invalid headers are rejected.

Data Isolation

User data is strictly isolated:

• Canvas positions: Each user has their own block positions, never shared
• Sessions: User sessions are scoped to the authenticated user
• Rooms and offices: Access is controlled by membership and permissions
• Admin actions: Admins can only access data within their role’s scope

Database queries use Prisma’s query builder, which prevents SQL injection attacks through parameterized queries. No raw database queries are executed.

Account Deletion

Users can delete their accounts through a confirmed flow:

1. User requests account deletion
2. System sends a confirmation email with a single-use token
3. Token expires in 30 minutes
4. User clicks the link to confirm deletion
5. Account and associated data are permanently removed

This two-step process prevents accidental deletions and ensures the user controls the action.

Monitoring and Health Checks

All services expose health check endpoints for monitoring:

• Backend: /health returns service status and database connectivity
• RPC Gateway: /health returns gateway status
• Web: Astro server health is monitored via uptime checks

Health checks are exempt from rate limiting to ensure monitoring systems can always verify service availability.

Security Roadmap

Ongoing security improvements include:

• Automated security scanning in CI/CD pipelines
• Dependency vulnerability monitoring with automated updates
• Penetration testing by third-party security firms
• Bug bounty program for responsible disclosure
• Security training for all team members
• Incident response plan with defined escalation paths

Security is a continuous process, not a one-time achievement. The platform evolves to address new threats and incorporate industry best practices.

Reporting Security Issues

If you discover a security vulnerability, please report it responsibly:

• Email: [email protected]
• Do not open public GitHub issues for security vulnerabilities
• Provide detailed reproduction steps and impact assessment
• Expect acknowledgment within 24 hours and resolution timeline within 72 hours

We take security reports seriously and work quickly to validate and fix confirmed vulnerabilities.