Principle:FlowiseAI Flowise Chatflow Security Configuration
| Attribute | Value |
|---|---|
| Page Name | Chatflow_Security_Configuration |
| Workflow | Chatbot_Deployment |
| Repository | FlowiseAI/Flowise |
| Domain | Security, Deployment, Access Control |
| Source | packages/ui/src/api/chatflows.js:L13, packages/ui/src/ui-component/dialog/ChatflowConfigurationDialog.jsx, packages/ui/src/ui-component/extended/Security.jsx, packages/ui/src/ui-component/extended/RateLimit.jsx, packages/ui/src/ui-component/extended/AllowedDomains.jsx, packages/ui/src/ui-component/extended/OverrideConfig.jsx |
| Last Updated | 2026-02-12 14:00 GMT |
Overview
Technique for configuring security policies on deployed chatflows including rate limiting, domain whitelisting, and parameter override control.
Description
Before deploying a chatflow publicly, security must be configured at three levels:
- Rate Limiting controls request frequency per client to prevent abuse. It enforces a maximum number of requests (
limitMax) within a specified time window (limitDurationin seconds). When the limit is exceeded, a configurable error message is returned to the client.
- Allowed Domains restricts which origins can access the chatflow API via CORS (Cross-Origin Resource Sharing). When enabled, only requests originating from whitelisted domains are permitted. Requests from non-whitelisted origins receive a configurable error message.
- Override Configuration controls which node parameters can be modified at runtime via the API. This prevents callers from arbitrarily changing model settings, prompt templates, or credentials through the
overrideConfigrequest body property. Each node parameter must be explicitly enabled for override.
These settings are stored as a JSON string in the chatflow's apiConfig field. The JSON structure contains three top-level keys corresponding to each security layer:
{
"rateLimiting": {
"limitMax": 10,
"limitDuration": 60,
"message": "Rate limit exceeded"
},
"allowedDomains": {
"status": true,
"origins": ["https://example.com"],
"errorMessage": "Origin not allowed"
},
"overrideConfig": {
"status": true,
"nodes": ["chatOpenAI_0"],
"variables": [{"id": "var1", "name": "apiKey", "type": "string", "enabled": true}]
}
}
The UI manages these settings through a tabbed dialog: ChatflowConfigurationDialog.jsx (166 lines) provides the container, while Security.jsx, RateLimit.jsx (182 lines), AllowedDomains.jsx (208 lines), and OverrideConfig.jsx (473 lines) handle each security concern independently.
Usage
Use this principle when hardening a chatflow for production deployment with access control and abuse prevention. Apply this technique before making a chatflow public or distributing API keys, especially when the chatflow will be exposed to untrusted clients.
Applicability
- Rate Limiting: Apply when the chatflow is accessible over the internet or to a large number of users to prevent resource exhaustion and API abuse.
- Allowed Domains: Apply when the chatflow is embedded in specific websites and should not be callable from arbitrary origins.
- Override Configuration: Apply when the chatflow exposes parameters that should not be modified by external callers (e.g., API keys, model selection, system prompts).
Theoretical Basis
This technique implements the defense-in-depth security pattern. Multiple independent security layers (rate limiting, CORS, parameter locking) provide protection even if one layer is bypassed. The configuration is persisted per-chatflow, enabling different security postures per deployment.
Rate limiting follows the token bucket algorithm pattern, where each client has a fixed budget of requests that refills over time. This prevents both deliberate abuse and accidental overloading.
CORS-based domain whitelisting leverages the browser's same-origin policy enforcement. While not a substitute for server-side authentication (since non-browser clients can forge headers), it provides an effective layer for browser-based widget deployments.
Override configuration control implements the principle of least privilege at the API parameter level. By defaulting to locked (override disabled) and requiring explicit opt-in per parameter, it prevents unintended exposure of internal node settings.
The per-chatflow storage model means each deployed chatflow can have an independent security configuration tailored to its specific deployment context and risk profile.