Skip to main content

Platform Security & Hardening

Forge is designed with secure-by-default architecture, protecting your application against common OWASP vulnerabilities (CSRF, session fixation, timing attacks, and password truncation) out of the box.

CSRF Protection & Exempt Paths​

Forge integrates Gorilla CSRF middleware to defend state-changing HTTP requests (POST, PUT, PATCH, DELETE).

How It Works​

  1. For HTML/SPA requests, Forge issues a cryptographically masked CSRF token via an HttpOnly cookie or header.
  2. Form submissions or AJAX calls must provide the token via the X-CSRF-Token header or gorilla.csrf.Token form field.

Configuring CSRF Exempt Paths​

Public webhook listeners (e.g. Stripe, PayPal, GitHub webhooks) and stateless REST APIs authenticated via bearer tokens must bypass CSRF verification. Configure exempt paths in config/config.yaml:

security:
  csrf_enabled: true
  csrf_exempt_paths:
    - "/api/v1/*"
    - "/webhooks/stripe"
    - "/webhooks/logistics"

In Go code, the middleware automatically validates the request URL path prefix against registered exempt patterns.

Secret Keys Configuration​

Forge requires 3 distinct 32-byte cryptographically secure keys:

security:
  secret_key: "your-32-byte-hex-encoded-app-secret"
  csrf_secret_key: "your-32-byte-csrf-encryption-key"
  session_secret: "your-32-byte-session-cookie-secret"
Production Recommendation

If keys are omitted during development, Forge generates ephemeral random keys and prints a warning in the console. For production deployments, always provide fixed keys via environment variables or secrets managers (FORGE_SECURITY_SECRET_KEY, etc.) so that active user sessions survive server restarts.

Secure Session Cookies​

All cookies generated by Forge adhere to strict security best practices:

  • HttpOnly: true: JavaScript cannot access cookies, neutralizing Cross-Site Scripting (XSS) session theft.
  • SameSite: Lax / Strict: Blocks cross-site request leakage.
  • Secure: true: When app.env is production, cookies are only transmitted over TLS/HTTPS.

Password Hashing: Bcrypt with Double-Hash Defense​

Bcrypt has a well-known vulnerability: passwords longer than 72 bytes are silently truncated.

Forge mitigates this by passing incoming passwords through a SHA-256 pre-hash before feeding into Bcrypt (cost factor 12):

  1. Any password (whether 8 characters or 500 characters) is hashed to a fixed 32-byte SHA-256 digest.
  2. The digest is then processed by Bcrypt with a cryptographic salt.
  3. This eliminates the 72-byte truncation boundary completely while preserving Bcrypt's resistance to GPU hardware attacks.

CORS (Cross-Origin Resource Sharing)​

Configure permitted browser origins for frontend clients in config/config.yaml:

server:
  cors:
    enabled: true
    allowed_origins:
      - "http://localhost:3000"
      - "https://store.example.com"
    allowed_methods:
      - "GET"
      - "POST"
      - "PUT"
      - "PATCH"
      - "DELETE"
      - "OPTIONS"
    allowed_headers:
      - "Content-Type"
      - "Authorization"
      - "X-CSRF-Token"
    allow_credentials: true
    max_age: 86400

Security Headers​

Forge automatically injects essential security response headers:

  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY (or SAMEORIGIN for Admin embedding)
  • X-XSS-Protection: 1; mode=block
  • Strict-Transport-Security: max-age=31536000; includeSubDomains (when TLS is active)

Next Steps​