Security Hardening

CORS, security headers, cookies, session management, and infrastructure security for Aidbox.

This page describes infrastructure-level security features in Aidbox: CORS, security headers, cookie flags, session management, and what is not implemented. Use it together with Access Policies, Audit and Logging, and User management for a complete security picture.

CORS

Cross-Origin Resource Sharing (CORS) is enabled by default. Aidbox supports:

  • Wildcard mode — BOX_SECURITY_CORS_ORIGINS=* (default). Any Origin header is echoed back in Access-Control-Allow-Origin. Use only in development or when all origins are trusted.
  • Whitelist mode — Set BOX_SECURITY_CORS_ORIGINS to a comma-separated list of origins, e.g. https://app.example.com,https://trusted.example.com. Only those origins receive CORS headers; requests from other origins get no Access-Control-* headers (but the API still responds).
  • Disabled — Set BOX_SECURITY_CORS_ENABLED=false to disable CORS entirely.

Preflight OPTIONS requests are handled: allowed methods and requested headers are reflected in Access-Control-Allow-Methods and Access-Control-Allow-Headers. Credentials are supported (Access-Control-Allow-Credentials: true). Settings can be changed at runtime via the Settings API (or environment variables).

See security.cors.enabled and security.cors.origins.

Cookie security

Session cookies set by Aidbox (e.g. after login) use:

  • HttpOnly — set, to reduce XSS-based cookie theft
  • SameSite=Lax — set, to reduce CSRF from cross-site requests

The Secure flag is not set by Aidbox. When Aidbox is behind HTTPS (e.g. reverse proxy), consider configuring the proxy or application to set Secure on cookies if your deployment supports it.

Session and token management

  • Session expiration — Default session (cookie) lifetime is configurable (e.g. via AuthConfig). Expired sessions are cleaned up automatically.
  • Access token expiration — Configurable per Client (e.g. auth.client_credentials.access_token_expiration). Tokens are rejected after expiry (401).
  • Sessions list — Active sessions can be inspected via the Session resource (if available in your setup).

See OAuth 2.0 and Client management.

What is not implemented

The following are not implemented in Aidbox. Rely on operational measures or reverse proxy where needed:

FeatureDescription
Rate limitingNo request throttling on API or auth endpoints. Use a reverse proxy or WAF for rate limiting.
Brute-force protectionNo automatic account lockout after failed login attempts. Use the User.inactive flag to lock accounts manually, or implement throttling at the proxy.
HSTSHeader not set. Add at reverse proxy when using HTTPS.
X-Content-Type-Options / Referrer-PolicyNot set. Add at reverse proxy for defense in depth.

Infrastructure recommendations

  • TLS — Terminate TLS at a reverse proxy or load balancer. Do not expose Aidbox directly to the internet without encryption.
  • Reverse proxy — Use nginx, Traefik, or similar to add security headers (HSTS, X-Content-Type-Options, Referrer-Policy), rate limiting, and DDoS mitigation.
  • Network — Restrict access to Aidbox and the database to trusted networks where possible.

See also

Last updated: