Skip to content
ABRQ DATADocs Abrq DIP · latest
Product page Request a trial
On this page

Transport Security and Egress Controls

HTTPS enforcement in production#

With ABRQ_ENV=prod, the backend rejects non-HTTPS requests with HTTP 400. The guard honors the X-Forwarded-Proto header, so it works behind a reverse proxy that terminates TLS and forwards the original scheme.

If your load balancer terminates TLS and strips the forwarded scheme, set ABRQ_ALLOW_INSECURE=1 to disable the guard — an explicit "I know my LB handles TLS" override, not a default:

ABRQ_ENV=prod
ABRQ_ALLOW_INSECURE=1

Warning. Only set ABRQ_ALLOW_INSECURE=1 when TLS genuinely terminates in front of the backend. It disables the platform's own transport check entirely.

HSTS and security headers#

  • HSTS is opt-in via ABRQ_ENABLE_HSTS=true (the Helm chart sets it by default; enable it anywhere the deployment is reliably served over HTTPS).
  • Every response carries hardening headers: a Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin.

CORS — explicit origins only#

ABRQ_CORS_ALLOWED_ORIGINS is a comma-separated list of exact origins allowed to call the API from a browser. There is no wildcard mode:

  • Production deployments must set it explicitly (the production compose file refuses to start without it).
  • An empty list means no browser origin is allowed — non-browser clients (server-to-server, CLI) are unaffected, but the web UI must be served from a listed origin.
ABRQ_CORS_ALLOWED_ORIGINS=https://dip.example.com

SSRF and egress protection#

Abrq DIP makes many outbound connections on your behalf — stream destinations, notification webhooks, AI provider endpoints, S3-compatible custom endpoints, and the audit forwarder. A user who can configure a URL must not be able to point the platform at your internal infrastructure, so outbound targets pass through an egress guard:

  • ABRQ_SSRF_PROTECTION (default true) resolves each outbound host and blocks destinations in loopback, link-local (including the cloud metadata address 169.254.169.254), private, and reserved ranges.
  • ABRQ_EGRESS_ALLOWED_INTERNAL_HOSTS is a comma-separated, exact-match hostname allowlist for the legitimate exceptions — an internal SIEM or an in-network MinIO endpoint. Only the named hosts are exempted; there is no wildcard or subnet form.
ABRQ_SSRF_PROTECTION=true
ABRQ_EGRESS_ALLOWED_INTERNAL_HOSTS=minio.internal.example.com,siem.internal.example.com

Note. The guard protects outbound requests the platform originates from user-configured URLs. Database connectors are configured by instance editors and connect wherever they are pointed — govern connector creation with global roles.

Webhook trigger rate limit#

Inbound run-trigger webhooks are rate-limited per token via ABRQ_WEBHOOK_RATE_LIMIT (default 60/minute). A leaked or misbehaving webhook token can re-trigger runs, but not stampede the platform. This is in addition to the API-wide limit of 100 requests per minute and the login limit of 10 per minute (see Authentication).

The platform is designed so that only the frontend port needs to be exposed:

  • The web UI serves the SPA and proxies /api to the backend; nothing else needs to be reachable from users' networks.
  • In the production and release compose files, PostgreSQL and Redis publish no host ports — they are reachable only on the internal container network. Keep it that way; neither service is meant to face users.
  • In Kubernetes, all services are ClusterIP; expose the frontend (and the /api path) through your Ingress, and nothing else.
  • Production compose requires a Redis password; the Helm chart enables Redis auth by default.
  • If you front the deployment with a corporate proxy or WAF, terminate TLS there and use the X-Forwarded-Proto behavior described above.

For per-path exposure details, see Docker Compose and Kubernetes. For the environment variables named on this page, see environment variables.