Attack Mode

Protect your deployed applications from DDoS attacks and bot traffic with a built-in proof-of-work challenge system. No third-party CAPTCHA services, no external dependencies -- everything runs on your infrastructure.

Overview

Attack Mode is Temps's self-hosted alternative to Cloudflare's "Under Attack Mode." When enabled, every visitor must complete a proof-of-work (PoW) challenge before accessing your application. The challenge is solved automatically in the visitor's browser using a WebAssembly solver -- no user interaction required.

How It Works

When a visitor requests a page on a project with Attack Mode enabled, the Temps proxy intercepts the request and runs through the following flow:

Challenge Flow

1. Request arrives at the Pingora-based reverse proxy
2. Session check -- the proxy looks up the visitor's JA4 TLS fingerprint (or IP address as fallback) in the challenge_sessions table
3. If valid session exists -- the request passes through to your application normally
4. If no valid session -- the proxy returns a 403 response with an HTML challenge page
5. Browser solves challenge -- the embedded WASM solver finds a nonce such that SHA-256(challenge + nonce) has at least 20 leading zero bits (~1 million hash attempts, takes 2-5 seconds)
6. Solution submitted -- the browser POSTs the solution to /api/_temps/captcha/verify
7. Server verifies -- the proxy recomputes the hash and checks the leading zero bits
8. Session created -- a 24-hour session is stored in the database, keyed to the visitor's TLS fingerprint
9. Page loads -- the browser redirects to the original URL

Proof-of-Work Details

The challenge uses SHA-256 hashing with a difficulty of 20 leading zero bits, which requires approximately 1 million hash attempts on average. The WASM solver processes this in 2-5 seconds on modern hardware.

Enabling Attack Mode

Attack Mode can be enabled from the dashboard, CLI, or API.

Via Dashboard

1. Go to Projects and select your project
2. Open Settings → Security
3. Toggle Enable Attack Mode in the Attack Mode card
4. Click Save Attack Mode Settings

When enabled, an orange banner appears on the project detail page:

Attack Mode is enabled for this project -- with a quick-access Disable button to turn it off immediately.

Via CLI

# Enable attack mode on a project
bunx @temps-sdk/cli projects settings -p my-app --attack-mode

Via API

# Enable attack mode
curl -X PATCH "https://your-temps-instance.com/api/projects/{project_id}/settings" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"attack_mode": true}'

# Disable attack mode
curl -X PATCH "https://your-temps-instance.com/api/projects/{project_id}/settings" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"attack_mode": false}'

Per-Environment Override

Attack mode can also be toggled per environment (e.g., enable only for production, not staging):

1. Go to Project Settings → Environments
2. Select the environment (production, staging, preview)
3. Open the Security card
4. Toggle Attack Mode for that specific environment

Security Headers

Temps automatically applies configurable HTTP security headers to all responses from your deployed applications. Headers can be configured at three levels: global, project, and environment.

Presets

Choose from built-in presets or configure headers individually:

Headers Configured

Configuring Headers

1. Global:      Settings → Security → Security Headers
2. Project:     Project Settings → Security → Security Headers
3. Environment: Project Settings → Environments → [env] → Security

IP Access Control

Control access to your Temps instance at the infrastructure level with IP-based allow and block lists. Rules are enforced at the proxy layer before requests reach your applications.

# Block an IP
curl -X POST ".../api/ip-access-control" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "ip_address": "192.168.1.100",
    "action": "block",
    "reason": "Suspicious activity"
  }'

# Check if an IP is blocked
curl ".../api/ip-access-control/check/192.168.1.100" \
  -H "Authorization: Bearer YOUR_TOKEN"

Rate Limiting

Configure per-IP request rate limits to protect against abuse. Rate limiting is available at the global, project, and environment levels.

Configuring Rate Limits

1. Global:      Settings → Security → Rate Limiting
2. Project:     Project Settings → Security → Rate Limiting
3. Environment: Project Settings → Environments → [env] → Security

Vulnerability Scanning

Temps automatically scans your deployed Docker images for known vulnerabilities using Trivy, an open-source security scanner. Scans run daily at midnight UTC and can also be triggered manually.

What Gets Scanned

• OS packages (Alpine, Debian, Ubuntu, etc.) -- detects CVEs in system libraries
• Language packages (npm, pip, Go modules, etc.) -- detects CVEs in application dependencies
• Container configuration -- checks for security misconfigurations

Severity Levels

Viewing Scan Results

1. Go to Projects and select your project
2. Vulnerability scan results appear in the project overview
3. Each scan shows total count and breakdown by severity (critical, high, medium, low)
4. Click into a scan to see individual CVEs with package names, installed versions, fixed versions, and CVSS scores

Triggering a Manual Scan

# Via API
curl -X POST "https://your-temps-instance.com/api/projects/{project_id}/scans" \
  -H "Authorization: Bearer YOUR_TOKEN"

# View latest scan results
curl "https://your-temps-instance.com/api/projects/{project_id}/scans/latest" \
  -H "Authorization: Bearer YOUR_TOKEN"

# View vulnerabilities for a specific scan
curl "https://your-temps-instance.com/api/projects/{project_id}/scans/{scan_id}/vulnerabilities" \
  -H "Authorization: Bearer YOUR_TOKEN"

Configuration Inheritance

Security settings follow a three-level inheritance chain. More specific settings override less specific ones:

Global Settings  →  Project Settings  →  Environment Settings
  (defaults)         (overrides global)    (overrides project)

What Inherits How

Next Steps

• Monitoring -- Monitor application health and resource usage
• Error Tracking -- Track and debug application errors
• Logs -- View application and deployment logs
• Architecture: Security -- Security architecture overview