Skip to content

Defense in Depth

Security is not a feature — it's the architecture. Trading platforms handle real money and broker credentials. A single vulnerability can mean unauthorized trades, stolen API keys, or drained accounts. 4pass implements 5 layers of defense-in-depth, ensuring that no single layer failure compromises the system. Every layer assumes the one above it has already been breached.

5 Security Layers

flowchart TB
    ATTACKER["Attacker"] --> L1
    L1["Layer 1: Network<br/>WAF, Rate Limiting, IP Reputation"] --> L2
    L2["Layer 2: Transport<br/>HTTPS/TLS, HSTS, SameSite Cookies"] --> L3
    L3["Layer 3: Authentication<br/>JWT, Sessions, API Keys, CAPTCHA, CSRF"] --> L4
    L4["Layer 4: Encryption<br/>RSA-4096, AES-256-GCM, KMS HSM"] --> L5
    L5["Layer 5: Application<br/>Webhook Validation, Audit Logging"] --> CORE
    CORE["Broker Credentials<br/>and Trading Operations"]

An attacker must defeat all 5 layers to reach trading operations. Each layer operates independently — compromising the WAF doesn't bypass authentication, and stealing a JWT doesn't decrypt broker credentials.

Security Summary

Layer Protection Implementation Attack Vectors Covered
Network WAF rules, rate limiting, IP filtering AWS WAFv2 with 7 rules (admin IP restriction, TradingView allowlist, login rate limit, blanket rate limit, 3 managed rule sets) DDoS, brute force, SQL injection, XSS, known exploits, bot traffic
Transport TLS encryption, strict transport, secure cookies ALB + ACM auto-renewing certificates, HSTS 1yr with preload, SameSite=strict MITM, session hijacking, cookie theft, protocol downgrade
Authentication Multi-factor verification, session management JWT (HS256) + Argon2id + Cloudflare Turnstile CAPTCHA + per-session CSRF tokens Credential stuffing, brute force, session fixation, CSRF
Encryption End-to-end credential protection RSA-4096 (KMS HSM) + AES-256-GCM + per-user isolation keys Data breach, credential theft, insider threat, memory dump
Application Webhook validation, audit trail, attack detection 4-layer webhook defense, Redis replay detection, real-time email alerts Replay attacks, unauthorized trading, webhook forgery

Key Security Properties

Credentials Are Never Stored in Plaintext

Broker API keys and secrets are encrypted with per-user AES-256-GCM keys before touching the database. Even a full database dump reveals nothing without the corresponding encryption keys.

RSA Private Key Never Leaves Hardware

The RSA-4096 private key used for frontend-to-backend encryption is managed by AWS KMS and stored in a FIPS 140-2 Level 3 Hardware Security Module. The key cannot be exported, extracted, or accessed in software — all decryption happens inside the HSM.

  • Per-user encryption keys — compromising one user's key doesn't affect any other user. Each trading account has a unique 32-byte encryption key, itself encrypted with the master key.
  • All security events are audited and alertable — the audit_logs table records every authentication attempt, webhook request, attack detection, and administrative action with full request context.
  • Constant-time comparisons prevent timing attacks — all secret comparisons (webhook secrets, CSRF tokens, API keys) use hmac.compare_digest() to eliminate timing side channels.
  • Replay detection with Redis-based deduplication — SHA-256 hashes of webhook payloads are stored in Redis with TTL-based expiration, preventing captured requests from being replayed.
  • Fail-open rate limiting — application-level rate limits use Redis sorted set sliding windows but fail open on Redis errors, ensuring trading operations are never blocked by cache failures.

Compliance Considerations

Standard Implementation
FIPS 140-2 Level 3 AWS KMS HSM for RSA-4096 key storage and all asymmetric decryption operations
OWASP Password Guidelines Argon2id (memory-hard, GPU-resistant) via pwdlib — the OWASP-recommended password hashing algorithm
Security Headers HSTS (1 year + includeSubDomains + preload), CSP, X-Frame-Options SAMEORIGIN, X-Content-Type-Options nosniff, COOP, CORP, Referrer-Policy, Permissions-Policy
Audit Trail Complete audit logging for all state-changing operations — user ID, IP address, User-Agent, request path, success/failure, error messages, and arbitrary metadata JSON
Encryption at Rest AES-256-GCM for credential storage, envelope encryption with KMS for key management
Encryption in Transit TLS 1.2+ via ALB + ACM, plus application-level RSA+AES hybrid encryption for credential submission

Section Overview

This security section provides detailed coverage of each layer:

Authentication

JWT tokens, Argon2id passwords, session management, CSRF protection, Cloudflare Turnstile CAPTCHA, API keys, IP whitelisting, and the complete middleware stack.

Encryption

RSA-4096 + AES-256-GCM hybrid encryption, AWS KMS HSM integration, per-user key isolation, encryption versioning, and the complete key hierarchy from browser to database.

Webhook Security

4-layer mandatory validation for TradingView webhooks — unique URL tokens, timestamp verification, secret authentication with constant-time comparison, and Redis-based replay detection.

Attack Detection

AWS WAF rules, application-level rate limiting, real-time attack classification, email alerting with rate limiting, comprehensive audit logging, and security headers.