Security & Responsibility Boundaries

🔒 Understand WEMAZU's security practices, platform responsibilities, and your responsibilities for deployed applications.

This document explains what WEMAZU secures, what you're responsible for, and how credentials and data are handled.

Table of Contents

  1. What WEMAZU Secures
  2. Your Responsibilities
  3. Credential Storage
  4. GitHub Trust Boundaries
  5. SIMEZU Trust Boundaries
  6. Data Encryption
  7. Best Practices

What WEMAZU Secures

Infrastructure Security

What WEMAZU Protects:

  • ✅ WEMAZU Platform: WEMAZU's own infrastructure and codebase
  • ✅ Database: WEMAZU's database (projects, deployments, logs)
  • ✅ API Security: Authentication, authorization, rate limiting
  • ✅ Network Security: HTTPS, secure connections to GitHub and SIMEZU

What WEMAZU Does NOT Protect:

  • ❌ Your Servers: Your FTP/SFTP/SSH servers are your responsibility
  • ❌ Your Applications: Security of your deployed applications
  • ❌ Your Domains: DNS configuration, SSL certificates for your domains

Authentication Security

WEMAZU Handles:

  • ✅ User Authentication: Via SIMEZU (headless SSO)
  • ✅ Token Management: Secure storage and validation of SIMEZU tokens
  • ✅ Session Management: Token-based sessions (no server-side sessions)
  • ✅ Authorization: Project ownership, deployment permissions

Security Features:

  • ✅ Tokens never stored in WEMAZU database
  • ✅ All authentication verified via SIMEZU API
  • ✅ No password storage (handled by SIMEZU)
  • ✅ Token expiration handled by SIMEZU

Deployment Pipeline Security

WEMAZU Secures:

  • ✅ GitHub Token Storage: Encrypted at rest (AES-256-CBC)
  • ✅ Server Credentials: Encrypted in database (if stored)
  • ✅ Webhook Secrets: Generated securely, validated on receipt
  • ✅ Deployment Execution: Secure connections (SFTP, SSH)

Security Measures:

  • ✅ GitHub tokens encrypted before storage
  • ✅ Server passwords not logged
  • ✅ Webhook signature validation (if secret configured)
  • ✅ Secure file transfers (SFTP, not plain FTP when possible)

Your Responsibilities

Application Security

You Are Responsible For:

  • ✅ Application Code: Security of your application code
  • ✅ Dependencies: Keeping dependencies updated, scanning for vulnerabilities
  • ✅ Input Validation: Validating and sanitizing user input
  • ✅ Authentication: Application-level authentication (if needed)
  • ✅ Authorization: Application-level access control
  • ✅ Data Protection: Protecting sensitive data in your application

WEMAZU Does NOT:

  • ❌ Scan your code for vulnerabilities
  • ❌ Update your dependencies
  • ❌ Validate your application's security
  • ❌ Monitor your application for attacks

Server Security

You Are Responsible For:

  • ✅ Server Hardening: Securing your servers (firewall, SSH keys, etc.)
  • ✅ Access Control: Managing server user accounts and permissions
  • ✅ Updates: Keeping server OS and software updated
  • ✅ Monitoring: Monitoring server security (intrusion detection, etc.)
  • ✅ Backups: Backing up your server data

WEMAZU Does NOT:

  • ❌ Manage your server security
  • ❌ Update your server software
  • ❌ Monitor your servers for security issues
  • ❌ Backup your server data

Secrets Management

You Are Responsible For:

  • ✅ Application Secrets: API keys, database passwords, etc. in your application
  • ✅ Environment Variables: Managing environment variables on your servers
  • ✅ Configuration Files: Securing configuration files (.env, etc.)
  • ✅ Database Credentials: Protecting database connection strings

WEMAZU Does NOT:

  • ❌ Manage your application secrets
  • ❌ Store your application secrets (except GitHub token, which is encrypted)
  • ❌ Inject secrets into your deployments
  • ❌ Manage environment variables on your servers

Domain and DNS Security

You Are Responsible For:

  • ✅ DNS Configuration: Setting up DNS records correctly
  • ✅ SSL Certificates: Obtaining and configuring SSL certificates
  • ✅ Domain Security: Protecting domain registrar accounts
  • ✅ DNS Security: DNSSEC, DNS filtering, etc.

WEMAZU Does NOT:

  • ❌ Manage your DNS
  • ❌ Provision SSL certificates
  • ❌ Validate domain ownership
  • ❌ Protect your domain registrar accounts

Credential Storage

GitHub Token Storage

Storage Location:

  • Table: user_github_tokens
  • Field: github_token_encrypted (TEXT)
  • Encryption: AES-256-CBC

Encryption Process:

  1. Token is received from user
  2. Validated with GitHub API
  3. Encrypted using AES-256-CBC
  4. Base64 encoded
  5. Stored in database

Encryption Key:

  • Source: GITHUB_TOKEN_ENCRYPTION_KEY environment variable
  • Fallback: Development key (if env var not set)
  • Length: 32 bytes (256 bits)

Decryption Process:

  1. Retrieve encrypted token from database
  2. Base64 decode
  3. Extract IV (first 16 bytes)
  4. Decrypt using AES-256-CBC
  5. Return plain text token

Code Example:

// Encryption
$iv = random_bytes(16);
$encrypted = openssl_encrypt($token, 'AES-256-CBC', $key, 0, $iv);
$encryptedToken = base64_encode($iv . $encrypted);

// Decryption
$data = base64_decode($encryptedToken);
$iv = substr($data, 0, 16);
$encrypted = substr($data, 16);
$token = openssl_decrypt($encrypted, 'AES-256-CBC', $key, 0, $iv);

Security Notes:

  • ✅ Tokens encrypted at rest
  • ✅ IV (Initialization Vector) is unique per encryption
  • ✅ Key stored in environment variable (not in code)
  • ⚠️ Development key is less secure (use env var in production)

Server Credentials Storage

Storage:

  • Server credentials stored in secure storage
  • Passwords and SSH keys are handled securely

Current Implementation:

  • ⚠️ Passwords: May be stored in plain text (check your implementation)
  • ✅ SSH Keys: Stored securely (if used)
  • ⚠️ Recommendation: Encrypt server passwords similar to GitHub tokens

Best Practice:

  • Use SSH keys instead of passwords when possible
  • Encrypt passwords if stored in database
  • Use environment variables for sensitive credentials
  • Rotate credentials regularly

SIMEZU Token Storage

Storage:

  • ❌ NOT stored in WEMAZU: SIMEZU tokens are never stored in WEMAZU database
  • ✅ Frontend only: Stored in localStorage or cookies (browser)
  • ✅ Stateless: Verified on each request via SIMEZU API

Token Flow:

  1. User logs in → SIMEZU returns token
  2. Token stored in browser (localStorage or cookie)
  3. Each API request includes token in Authorization header
  4. WEMAZU verifies token with SIMEZU API
  5. Token never stored in WEMAZU database

GitHub Trust Boundaries

What WEMAZU Can Do with Your GitHub Token

With repo Scope:

  • ✅ Read repository information (branches, commits, tags)
  • ✅ Download repository archives (for FTP/SFTP deployments)
  • ✅ Create webhooks (for auto-deploy)
  • ✅ List webhooks
  • ✅ Read webhook configurations

WEMAZU Does NOT:

  • ❌ Write to your repository (no push, no commits)
  • ❌ Delete repositories
  • ❌ Modify repository settings
  • ❌ Access private repositories you don't own (only your repos)

GitHub Webhook Security

Webhook Secret:

  • ✅ Generated automatically by WEMAZU (random string)
  • ✅ Stored securely per project
  • ✅ Used to validate webhook signatures from GitHub

Webhook Validation:
WEMAZU validates webhook signatures using HMAC-SHA256:

  • Extracts the signature from the X-Hub-Signature-256 header
  • Computes the expected signature using the webhook secret
  • Compares signatures using constant-time comparison
  • Rejects webhooks with invalid signatures

Security Notes:

  • ✅ Webhook signatures validated (if secret configured)
  • ✅ Webhook URL must be publicly accessible (GitHub requirement)
  • ⚠️ localhost URLs are rejected by GitHub

GitHub API Rate Limits

Rate Limits:

  • Authenticated requests: 5,000 requests/hour
  • Unauthenticated requests: 60 requests/hour

WEMAZU Usage:

  • Repository info: ~1 request per project load
  • Archive download: 1 request per deployment (FTP/SFTP)
  • Webhook creation: 1 request per webhook setup
  • Branch listing: ~1 request per project load

Best Practice:

  • WEMAZU uses your GitHub token (authenticated)
  • Rate limits are per-token, not per-WEMAZU-instance
  • If you hit rate limits, wait or use a different token

SIMEZU Trust Boundaries

What WEMAZU Receives from SIMEZU

User Data:

  • ✅ User ID (id)
  • ✅ Email (email)
  • ✅ Name (firstName, lastName)
  • ✅ Roles (roles array)
  • ✅ Super Admin status (is_super_admin)

What WEMAZU Does NOT Receive:

  • ❌ Password (never sent)
  • ❌ Payment information
  • ❌ Personal data beyond name/email

SIMEZU Token Usage

Token Verification:

  • ✅ Every API request verifies token with SIMEZU
  • ✅ Endpoint: GET /simezu/api/auth/me
  • ✅ Token validated on each request (stateless)

Token Storage:

  • ❌ NOT stored in WEMAZU database
  • ✅ Stored in browser (localStorage or cookie)
  • ✅ Sent in Authorization header on each request

SIMEZU API Authentication

WEMAZU App Credentials:

  • App ID and API Key are configured via environment variables
  • Used for app-level API calls (not user authentication)
  • Example: Getting user roles with app context

Note: These credentials are configured by WEMAZU administrators and are not exposed to users.

Data Encryption

Encryption at Rest

What is Encrypted:

  • ✅ GitHub Tokens: AES-256-CBC encryption
  • ⚠️ Server Passwords: May not be encrypted (check implementation)
  • ❌ Other Data: Project names, domain names, etc. are not encrypted

Encryption Keys:

  • GitHub Token Key: GITHUB_TOKEN_ENCRYPTION_KEY environment variable
  • SIMEZU Token Key: SIMEZU_TOKEN_ENCRYPTION_KEY environment variable
  • Fallback: Development key (less secure, for development only)

Encryption in Transit

What is Encrypted:

  • ✅ HTTPS: All WEMAZU API requests over HTTPS
  • ✅ SFTP: Secure file transfers (if using SFTP)
  • ✅ SSH: Secure shell connections (if using SSH)
  • ⚠️ FTP: Plain FTP is not encrypted (use SFTP when possible)

TLS/SSL:

  • WEMAZU API should use HTTPS (TLS 1.2+)
  • GitHub API uses HTTPS
  • SIMEZU API uses HTTPS

Encryption Best Practices

For WEMAZU Administrators:

  1. ✅ Set GITHUB_TOKEN_ENCRYPTION_KEY in production
  2. ✅ Set SIMEZU_TOKEN_ENCRYPTION_KEY in production
  3. ✅ Use strong, random keys (32+ bytes)
  4. ✅ Rotate keys periodically
  5. ✅ Never commit keys to version control

For Users:

  1. ✅ Use HTTPS for WEMAZU access
  2. ✅ Use SFTP instead of FTP when possible
  3. ✅ Use SSH keys instead of passwords when possible
  4. ✅ Rotate GitHub tokens periodically

Best Practices

For WEMAZU Administrators

  1. Environment Variables:

    • Set encryption keys in environment variables
    • Never hardcode keys in code
    • Use different keys for production and development

  2. Database Security:

    • Use strong database passwords
    • Limit database access (firewall, IP whitelist)
    • Regular database backups

  3. API Security:

    • Use HTTPS for all API endpoints
    • Implement rate limiting
    • Validate all inputs
    • Use prepared statements (SQL injection prevention)

  4. Server Security:

    • Keep WEMAZU server updated
    • Use firewall to restrict access
    • Monitor for security issues
    • Regular security audits

For Users

  1. GitHub Token:

    • Use minimum required scope (repo or public_repo)
    • Rotate tokens periodically (every 90 days)
    • Revoke tokens if compromised
    • Use different tokens for different purposes

  2. Server Credentials:

    • Use strong passwords
    • Use SSH keys instead of passwords when possible
    • Rotate credentials regularly
    • Never share credentials

  3. Application Security:

    • Keep dependencies updated
    • Scan for vulnerabilities
    • Use environment variables for secrets
    • Implement input validation

  4. Domain Security:

    • Use HTTPS (SSL certificates)
    • Protect domain registrar accounts
    • Monitor DNS for changes
    • Use DNSSEC if available

Security Incidents

If Your GitHub Token is Compromised

Immediate Actions:

  1. ✅ Revoke token in GitHub: Settings → Developer settings → Personal access tokens
  2. ✅ Generate new token
  3. ✅ Update token in WEMAZU: Settings → GitHub Connection
  4. ✅ Check GitHub for unauthorized activity

Prevention:

  • Use minimum required scope
  • Rotate tokens regularly
  • Monitor GitHub for suspicious activity

If Your Server is Compromised

Immediate Actions:

  1. ✅ Change all server passwords
  2. ✅ Rotate SSH keys
  3. ✅ Check for unauthorized access
  4. ✅ Review server logs
  5. ✅ Consider rebuilding server

Prevention:

  • Keep server updated
  • Use firewall
  • Use SSH keys instead of passwords
  • Monitor server logs

If WEMAZU Platform is Compromised

WEMAZU Will:

  1. ✅ Notify affected users
  2. ✅ Investigate the incident
  3. ✅ Rotate compromised credentials
  4. ✅ Provide guidance on next steps

You Should:

  1. ✅ Rotate your GitHub token
  2. ✅ Rotate server credentials
  3. ✅ Review your deployments
  4. ✅ Check for unauthorized changes

Compliance

GDPR

WEMAZU Compliance:

  • ✅ User data stored only as necessary
  • ✅ Data can be exported (see Exiting WEMAZU)
  • ✅ Data can be deleted on request
  • ✅ No user data shared with third parties (except SIMEZU for authentication)

Your Responsibilities:

  • ✅ Ensure your application is GDPR compliant
  • ✅ Handle user data according to GDPR
  • ✅ Provide privacy policy
  • ✅ Handle data deletion requests

Data Residency

Current Status:

  • ⚠️ Data stored in WEMAZU's database location
  • ⚠️ Check WEMAZU's data residency policy

Your Responsibilities:

  • ✅ Ensure your application meets data residency requirements
  • ✅ Choose servers in appropriate regions
  • ✅ Configure backups in appropriate regions

Summary

WEMAZU Secures

  • ✅ Platform infrastructure
  • ✅ Authentication and authorization
  • ✅ GitHub token encryption
  • ✅ Deployment pipeline security
  • ✅ API security (HTTPS, rate limiting)

You Are Responsible For

  • ✅ Application security
  • ✅ Server security
  • ✅ Secrets management
  • ✅ Domain and DNS security
  • ✅ Compliance (GDPR, etc.)

Trust Boundaries

  • GitHub: WEMAZU can read repos and create webhooks (with your token)
  • SIMEZU: WEMAZU verifies authentication (no password storage)
  • Your Servers: You manage security, WEMAZU only deploys

Next Steps: