Skip to main content
Securing your Figranium instance is critical, especially when running on a public server.

​
1. Authentication

By default, the Figranium UI requires an account. When you create your account during initial setup, Figranium enforces the following requirements:
  • Name: Must be 100 characters or fewer.
  • Email: Must be a valid email address (max 255 characters).
  • Password: Must be between 8 and 128 characters long.
All fields must be plain text strings. Requests with missing fields or values that exceed these limits are rejected with a 400 error. After setup, you should also:
  • API Key: Generate a strong API key in Settings > System. All API keys are limited to 512 characters.
  • Rotate: Regularly regenerate the API key if you suspect it’s compromised.
  • Header: Always use x-api-key or Authorization: Bearer for API calls.

​
2. IP Allowlist (ALLOWED_IPS)

The most effective way to secure a deployment is to restrict access to trusted IP addresses.
  • Environment Variable: ALLOWED_IPS
  • Example: ALLOWED_IPS=127.0.0.1,192.168.1.5,10.0.0.0/8
  • Config File: Alternatively, edit data/allowed_ips.json.
This blocks unauthorized traffic at the network level before it reaches the application logic.

​
3. SSRF Protection (ALLOW_PRIVATE_NETWORKS)

Server-Side Request Forgery (SSRF) is a risk when allowing users to trigger scrapes of arbitrary URLs.
  • Default: ALLOW_PRIVATE_NETWORKS=true (convenient for local dev).
  • Production: Set ALLOW_PRIVATE_NETWORKS=false.
    • This prevents users from scanning your internal network (e.g., http://169.254.169.254/latest/meta-data).
    • It blocks RFC 1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and IPv6 private ranges.
Protocol validation is always enforced regardless of the ALLOW_PRIVATE_NETWORKS setting. Only http: and https: URLs are allowed. Schemes such as file://, ftp://, and javascript: are blocked even when private network access is enabled. SSRF protection also applies to output provider credentials. When you add or update a credential with a baseUrl (for example, a Baserow instance URL), Figranium validates the URL to block requests to private or internal network addresses. If the URL fails validation, the credential is rejected with an INVALID_BASE_URL error.

​
Redirect protection

When ALLOW_PRIVATE_NETWORKS is false, all outbound HTTP requests — including webhook callbacks and output provider requests (such as Baserow) — are protected against redirect-based SSRF attacks. If a URL returns a redirect (HTTP 3xx), Figranium validates the destination URL at every hop before following it. This prevents an attacker from providing a URL that initially resolves to a public address but redirects to a private one (such as 169.254.169.254 or localhost).
  • Up to 5 redirects are followed per request. If this limit is exceeded, the request fails.
  • Each redirect destination is checked against the same private-IP blocklist used for scrape URLs.
  • No configuration is needed — this protection is automatic when ALLOW_PRIVATE_NETWORKS=false.
  • Redirects that change method (HTTP 301, 302, 303) automatically switch to GET and drop the request body, following HTTP standards.

​
Cross-origin credential stripping

When a redirect crosses origin boundaries (for example, from api.baserow.io to a different domain), Figranium automatically strips sensitive headers from the redirected request. This prevents credentials from leaking to untrusted third-party servers. The following headers are removed on cross-origin redirects:
  • Authorization
  • X-API-Key
  • Token
  • Cookie
  • Proxy-Authorization
This protection applies to all outbound requests that follow redirects, including output provider pushes and webhook callbacks. No configuration is required — it is always active.

​
Browser navigation protection

When ALLOW_PRIVATE_NETWORKS is false, Figranium also guards against SSRF at the browser level. Every cross-origin navigation in a scrape, headful, or agent browser session is validated before the request leaves the browser. If a page attempts to navigate to a private network address, the navigation is blocked.
  • Same-origin navigations (where the destination shares the same origin as the current page) are allowed without additional checks.
  • Only top-level navigations are validated; sub-resource requests (images, scripts, etc.) are not intercepted.
  • Blocked navigations are logged to the server console with a [SECURITY] prefix.

​
DNS validation caching

To reduce the overhead of repeated DNS lookups during URL validation, Figranium caches hostname resolution results for 30 seconds. Both allowed and blocked hostnames are cached, so subsequent requests to the same host resolve instantly. The cache is cleared automatically after the TTL expires.

​
4. Session Security

  • Session Lifetime: Dashboard sessions expire after 7 days of inactivity. You will need to log in again after this period.
  • HTTPS: Always run Figranium behind a reverse proxy (Nginx, Caddy) that handles TLS/SSL.
  • Secure Cookies: Set SESSION_COOKIE_SECURE=true in your .env file to ensure cookies are only sent over HTTPS. Session cookies are always set with the httpOnly flag, which prevents client-side JavaScript from accessing the session token and mitigates XSS-based session theft.
  • HSTS: When SESSION_COOKIE_SECURE is enabled, Figranium automatically sets Strict-Transport-Security headers (max-age=31536000; includeSubDomains) on every response. This instructs browsers to only communicate with your instance over HTTPS for one year, preventing protocol-downgrade attacks.
  • Strong Secret: Ensure SESSION_SECRET is a long, random string.

​
5. Reverse proxy and TRUST_PROXY

If you run Figranium behind a reverse proxy (Nginx, Caddy, AWS ALB), you should set TRUST_PROXY=true so the server can read the real client IP from proxy headers for logging and rate limiting.
When TRUST_PROXY is enabled, headers like X-Forwarded-For are trusted for general request metadata. However, security-sensitive checks — such as verifying whether a request originates from the local machine — always use the actual TCP connection address. This means an external client cannot bypass API key authentication by spoofing proxy headers.
To stay secure with TRUST_PROXY enabled:
  • Only set TRUST_PROXY=true when Figranium is actually behind a trusted proxy.
  • Configure your proxy to overwrite (not append to) the X-Forwarded-For header so untrusted values from clients are stripped.
  • Combine with ALLOWED_IPS to restrict which addresses can reach the server.

​
6. Rate Limiting

Figranium includes built-in rate limiting to prevent abuse.
  • Authentication: Max 10 failed login attempts per 15 minutes (AUTH_RATE_LIMIT_MAX).
  • Data API: Max 100 data requests per 15 minutes (DATA_RATE_LIMIT_MAX).
  • Settings endpoints: API key, proxy, and other settings routes are rate-limited to prevent automated abuse.
Adjust these values in .env if legitimate traffic is being blocked.