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

> Explore TREK's robust security features. Discover AES-256 encryption, bcrypt hashing, TOTP 2FA, CSP headers, and rate limiting to protect your data.

- Repository: [Maurice/TREK](https://github.com/mauriceboe/TREK)
- Tags: deep-dive
- Published: 2026-07-03

---

**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:

```bash
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`](https://github.com/mauriceboe/TREK/blob/main/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`](https://github.com/mauriceboe/TREK/blob/main/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`](https://github.com/mauriceboe/TREK/blob/main/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:

```bash

# .env

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

```

Rotate JWT secrets via API:

```bash
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:

```bash
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`](https://github.com/mauriceboe/TREK/blob/main/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`](https://github.com/mauriceboe/TREK/blob/main/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`](https://github.com/mauriceboe/TREK/blob/main/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.