Security Features in TREK: Data Encryption, 2FA, and Production Hardening

TREK ships with enterprise-grade security controls including AES-256-GCM encryption for secrets, bcrypt password hashing with cost factor 12, time-based one-time password (TOTP) 2FA, strict Content Security Policy headers, and configurable rate limiting to mitigate brute-force attacks.

TREK is an open-source platform designed with defense-in-depth principles that protect data at rest and in transit without requiring external security appliances. All security mechanisms are configurable through environment variables and admin API endpoints, allowing teams to enforce HTTPS, rotate JWT secrets, and encrypt backups using a single 32-byte master key. The following sections detail the implementation of these controls based on the mauriceboe/TREK source code.

Encryption and Secrets Management

TREK protects sensitive data using AES-256-GCM encryption for all stored secrets, including API keys and passwords.

The system requires a 32-byte ENCRYPTION_KEY set via environment variables. Generate this key using standard cryptographic tools:

openssl rand -hex 32

This produces a 64-character hexadecimal string that serves as the master encryption key. All secrets are encrypted before persistence to the database, ensuring that raw credentials never appear in storage. Backup files are also encrypted as ZIP archives using the same key, requiring secure offline storage of the key for disaster recovery.

Transport Layer Security and Network Controls

TREK enforces secure communications through TLS termination and network access controls designed for reverse proxy deployments.

Setting FORCE_HTTPS=true (automatically enabled in NODE_ENV=production) redirects all HTTP traffic to HTTPS and injects the upgrade-insecure-requests directive into the Content Security Policy header. When running behind nginx, Caddy, or Traefik, set TRUST_PROXY=1 to ensure TREK logs the actual client IP rather than the proxy address for audit purposes.

The platform also includes an ALLOW_INTERNAL_NETWORK flag that defaults to false, blocking all traffic from private LAN ranges except loopback and link-local addresses.

Authentication and Session Security

User authentication combines bcrypt hashing, signed JWT sessions, and hardened cookie attributes.

Passwords must meet a strict policy requiring minimum eight characters with mixed case, digits, and special characters. The system rejects common passwords and repetitive strings. All passwords are hashed using bcrypt with a cost factor of 12 before storage.

Upon authentication, TREK issues a session cookie named trek_session containing a signed JWT. In production environments, the cookie automatically receives the Secure, HttpOnly, and SameSite=Lax flags, preventing transmission over plaintext HTTP and protecting against cross-site scripting attacks.

The JWT verification logic resides in src/nest/auth/jwt-auth.guard.ts, which extracts the token from either the cookie or the Authorization: Bearer header and attaches the validated user object to the request.

Two-Factor Authentication

TREK supports time-based one-time password (TOTP) multifactor authentication for individual users or as a mandatory policy.

Administrators can enforce 2FA organization-wide through the admin UI or by calling the settings API endpoint. When enabled, users must provide a TOTP code after successful password verification to complete authentication.

Rate Limiting and Abuse Prevention

To mitigate brute-force attacks, TREK implements in-memory per-IP rate limiting on authentication endpoints defined in src/nest/auth/rate-limit.middleware.ts.

The default limits are:

• Login, Register, and Invite endpoints: 10 attempts per 15 minutes
• MFA verification: 5 attempts per 15 minutes
• Password changes: 5 attempts per 15 minutes
• MCP token creation: 5 attempts per 15 minutes

These restrictions apply per IP address and reset automatically after the window expires.

Content Security Policy

TREK uses Helmet to enforce a strict Content Security Policy (CSP) that mitigates cross-site scripting and injection attacks.

The default configuration includes:

• default-src 'self'
• script-src 'self' 'wasm-unsafe-eval'
• object-src 'none'
• frame-src 'none'
• frame-ancestors 'self'

Notably, the policy prohibits unsafe-inline scripts, requiring all JavaScript to load from the application's own origin.

Operational Security Controls

Beyond runtime protection, TREK provides administrative tools for JWT secret rotation, audit logging, and backup encryption.

The POST /api/admin/rotate-jwt-secret endpoint, implemented in src/nest/admin/admin.controller.ts, allows administrators to instantly invalidate all active sessions. Calling this endpoint generates a new signing secret, forcing every user to re-authenticate. The admin UI exposes this functionality via a "Rotate JWT Secret" button.

Every privileged operation—including user creation, permission changes, and JWT rotation—is recorded in an immutable audit log accessible via the UI or exportable through the API.

Configuration Examples

Enable production security headers and proxy trust:

# .env

FORCE_HTTPS=true
TRUST_PROXY=1
ENCRYPTION_KEY=9b1c...  # 64 hex characters from openssl rand -hex 32

Rotate JWT secrets via API:

curl -X POST "https://your.trek.instance/api/admin/rotate-jwt-secret" \
     -H "Authorization: Bearer <admin-jwt>" \
     -H "Content-Type: application/json"

Enforce MFA for all users:

curl -X PATCH "https://your.trek.instance/api/admin/settings" \
     -H "Authorization: Bearer <admin-jwt>" \
     -d '{"requireMfa":true}'

Summary

• AES-256-GCM encryption protects all stored secrets and backups using a configurable 32-byte master key.
• HTTPS enforcement and HSTS headers are activated via FORCE_HTTPS=true, with proxy support via TRUST_PROXY=1.
• Session cookies use HttpOnly, Secure, and SameSite=Lax attributes to prevent XSS and session hijacking.
• Bcrypt hashing with cost factor 12 and strict password policies protect user credentials.
• TOTP-based 2FA can be enforced globally through the admin API or UI.
• Rate limiting restricts authentication attempts to 5-10 requests per 15-minute window per IP.
• JWT secret rotation via src/nest/admin/admin.controller.ts provides immediate session invalidation capabilities.
• Immutable audit logs track all administrative actions and authentication events.

Frequently Asked Questions

How does TREK encrypt stored passwords and API keys?

TREK uses AES-256-GCM encryption for all secrets stored in the database, utilizing a 32-byte ENCRYPTION_KEY provided via environment variables. The encryption key must be generated using cryptographically secure random number generation (e.g., openssl rand -hex 32) and kept separate from backup files to ensure data recovery is possible only with the key.

What rate limits does TREK impose on authentication attempts?

According to src/nest/auth/rate-limit.middleware.ts, TREK enforces in-memory per-IP limits of 10 attempts per 15 minutes for login, registration, and invitation endpoints, and 5 attempts per 15 minutes for MFA verification, password changes, and MCP token creation. These limits help prevent brute-force attacks without requiring external rate-limiting infrastructure.

How can I force all users to use two-factor authentication?

Administrators can enforce TOTP-based 2FA globally by setting requireMfa: true via the admin settings API or toggling the "Require MFA for all users" option in the Admin → Permissions UI. Once enabled, existing users must configure 2FA on their next login, and new registrations will require TOTP setup before account creation completes.

How do I invalidate all active user sessions immediately?

Call the POST /api/admin/rotate-jwt-secret endpoint or click the "Rotate JWT Secret" button in the admin UI. This endpoint, defined in src/nest/admin/admin.controller.ts, generates a new JWT signing secret that instantly invalidates all existing trek_session cookies, forcing every user to re-authenticate with their credentials.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}