Security & Trust

Autoflowly is designed with security at every layer — from authentication and encryption to MVP isolation and rate limiting. This page documents the security measures in place.

Authentication

JWT Token Authentication

All API requests are authenticated with JSON Web Tokens (JWT):

  • Algorithm: HS256 (HMAC-SHA256)
  • Token expiry: 7-day access tokens with 30-day refresh tokens
  • Password hashing: bcrypt with automatic salting

OAuth 2.0 Providers

Sign in with your existing accounts — no new password required:

ProviderProtocolWhat's Verified
GoogleOAuth 2.0Email, profile, email verification status
GitHubOAuth 2.0GitHub identity, email
LinkedInOAuth 2.0Professional identity, email
EmailPasswordbcrypt-hashed, never stored in plaintext

All OAuth flows use server-side token exchange — client secrets never reach the browser.

Encryption

In Transit

  • TLS 1.2+ on all endpoints — enforced via cert-manager with Let's Encrypt certificates
  • HSTS header with max-age=31536000; includeSubDomains — browsers always use HTTPS
  • No plaintext HTTP — all connections redirect to HTTPS

At Rest

  • Fernet symmetric encryption module available for sensitive fields (AES-128-CBC)
  • Key derivation: PBKDF2-SHA256 with 100,000 iterations
  • Database credentials, API keys, and user secrets stored in Kubernetes Secrets (not in code)

MVP Isolation

Each generated MVP runs in its own isolated environment:

LayerIsolation Mechanism
ComputeDedicated Kubernetes pod per MVP — no shared processes
NetworkNetwork policies enforce default-deny ingress; only allowed traffic reaches each pod
StorageEach MVP has its own ConfigMap with file contents — no shared filesystem
URLUnique preview URL per MVP (mvp-{name}.preview.autoflowly.com)
LifecycleMVPs can be deleted independently without affecting other users

Network Policies

Autoflowly uses Kubernetes NetworkPolicy resources to enforce zero-trust pod-to-pod communication:

  • Default deny all ingress traffic
  • Explicit allow only for required service-to-service communication
  • Database access restricted to labeled backend pods only
  • Redis access restricted to authorized services
  • DNS egress limited to kube-system namespace

Rate Limiting

Autoflowly includes a multi-tier rate limiting system to protect against abuse.

Architecture

The rate limiting engine (AdvancedRateLimiter) supports tiered limits by identity:

TierDesigned Limit
Anonymous (IP-based)100 requests/minute
Authenticated user1,000 requests/minute
Premium user5,000 requests/minute

Endpoint-specific limits are configurable for sensitive routes like login and MVP generation.

Rate limit status headers are included in responses:

X-RateLimit-Limit: 60 X-RateLimit-Remaining: 60 X-RateLimit-Reset: 60

Security Headers

All responses include defensive HTTP headers:

HeaderValuePurpose
Strict-Transport-Securitymax-age=31536000; includeSubDomainsForce HTTPS
X-Frame-OptionsSAMEORIGINPrevent clickjacking
X-Content-Type-OptionsnosniffPrevent MIME-type sniffing
X-XSS-Protection1; mode=blockXSS filter
Referrer-Policystrict-origin-when-cross-originLimit referrer leakage
Content-Security-PolicyFrame-src allowlistRestrict embedded content

Input Validation

  • Pydantic schemas validate all API request bodies — type-checked, required fields enforced
  • Email validation via EmailStr type — rejects malformed addresses
  • SQL injection prevention — SQLAlchemy ORM with parameterized queries
  • File content sanitization — generated MVP code passes through SmartDoctor validation before deployment

Secrets Management

Secrets are managed through Kubernetes-native resources:

  • No secrets in source code — all credentials injected via Kubernetes Secrets
  • Environment-specific — separate secrets for dev, staging, and production
  • Rotation support — secrets can be updated without redeployment via rolling restart
  • Scoped access — each service only receives the secrets it needs

Managed secrets include: database URLs, Redis credentials, JWT signing keys, OAuth client secrets, AI provider API keys.

CORS Policy

Cross-Origin Resource Sharing is configured per environment:

  • Allowed origins — explicitly listed (no wildcards in production)
  • Credentials — enabled with proper origin validation
  • Methods — only required HTTP methods allowed per endpoint

Reporting Vulnerabilities

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

We take all reports seriously and aim to respond within 48 hours.