Skip to main content

​
Security Overview

Our primary goal is to ensure the protection and confidentiality of sensitive data stored by users on Open WebUI.
Open WebUI is designed as a self-hosted, authenticated platform with extensible role-based access control architecture.

​
Supported Versions

Version (Branch)Supported
main✅ Supported
dev❌ Not Supported
others❌ Not Supported
Only the main branch receives security updates. The dev branch and other branches are not supported for security fixes.

​
Security Best Practices

​
Authentication & Access Control

Enable Strong AuthenticationOpen WebUI supports multiple authentication methods:
  • LDAP/Active Directory integration
  • OAuth providers
  • SSO via trusted headers
  • SCIM 2.0 automated provisioning
Choose the authentication method that best fits your organization’s security requirements.
Role-Based Access Control (RBAC)
1

Create User Roles

Define detailed user roles with specific permissions for different user groups.
2

Restrict Model Access

Use RBAC to ensure only authorized individuals can access specific models.
3

Control Creation Rights

Reserve model creation and pulling rights for administrators only.

​
Deployment Security

Data PersistenceAlways mount a volume for data persistence:
-v open-webui:/app/backend/data
This prevents data loss and ensures your database is properly secured.
Database Security
Open WebUI supports multiple database options:
  • SQLite with optional encryption
  • PostgreSQL for production deployments
  • Cloud storage backends (S3, Google Cloud Storage, Azure Blob Storage)
For production environments, consider using PostgreSQL or encrypted SQLite.
Network Security 
# Use proper network configuration
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main
The backend reverse proxy design prevents direct exposure of the Ollama API to the frontend, safeguarding against CORS issues and unauthorized access.

​
Monitoring & Observability

Enable Logging
For production environments, enable JSON-formatted logging for log aggregators:
-e LOG_FORMAT=json
This makes logs suitable for tools like Loki, Fluentd, CloudWatch, and Datadog.
Audit Logging Enable audit logs to track user actions: 
-e ENABLE_AUDIT_STDOUT=true
OpenTelemetry Support Open WebUI has built-in OpenTelemetry support for:
  • Traces
  • Metrics
  • Logs
Integrate with your existing observability stack for comprehensive monitoring.

​
Configuration Security

Sensitive Environment VariablesNever commit files containing sensitive information:
  • .env files
  • credentials.json
  • API keys
  • OAuth secrets
Use environment variables or secrets management solutions instead.
Default Configuration Testing
Test your deployment with default security settings enabled. Only weaken security settings if absolutely necessary and document the reasons.

​
Function & Tool Security

Admin Control
Administrators have full system control and are expected to understand the security implications of their actions:
  • Adding external servers (models, tools, webhooks)
  • Deploying custom functions
  • Modifying security settings
Only grant admin access to trusted users.
Automatic Dependency Installation
For tighter control over function dependencies, disable automatic pip package installation:
-e ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS=false

​
Reporting a Vulnerability

​
Requirements for Valid Reports

Before submitting a vulnerability report, ensure it meets ALL of the following requirements:
A security vulnerability is an exploitable weakness where the system behaves in an unintended way, allowing attackers to:
  • Bypass security controls
  • Gain unauthorized access
  • Execute arbitrary code
  • Escalate privileges
Configuration options, missing features, and expected protocol behavior are NOT vulnerabilities.
Submissions such as “I found a vulnerability” without details will be treated as spam and rejected.
Reports must reflect a clear understanding of:
  • The codebase
  • How Open WebUI is used
  • Specific details about the vulnerability
  • Affected components
  • Potential impacts
Each submission must include a well-documented PoC that demonstrates:
  1. What security boundary was crossed
  2. How the vulnerability is triggered/abused
  3. What actions the attacker can perform
  4. What data/action becomes possible that should not be
  5. Exact reproduction steps (copy/paste runnable where possible)
Failure to provide a reproducible PoC may lead to closure of the report.
Along with the PoC, you must provide either:
  • A patch/PR, OR
  • A remediation plan with actionable steps
Include:
  • The likely root cause
  • Location(s) to change
  • Recommended fix approach
  • Security tradeoffs or potential regressions
All vulnerability reports must be tested using Open WebUI’s default configuration. Claims that only work with weakened security settings may be discarded.
Reports must demonstrate understanding of Open WebUI’s self-hosted, authenticated, role-based access control architecture.
If you include a CVSS score, it must accurately reflect the vulnerability. Intentionally inflated scores may result in report rejection.
Vulnerabilities requiring an administrator to actively perform unsafe actions are NOT valid. Admins have full system control and are expected to understand security implications.
You MUST DISCLOSE if AI was used in any capacity - whether for writing the report, generating the PoC, or identifying the vulnerability.

​
Where to Report

Report a Vulnerability

Open a vulnerability report on GitHub Security Advisories
Zero Tolerance for External PlatformsWe refuse to engage with, join, or monitor any platforms outside of GitHub for vulnerability reporting. Any reports arriving from sources other than our GitHub repository will be dismissed without consideration.

​
Non-Vulnerability Security Concerns

If your concern is security-related but NOT a vulnerability, use these channels:

Documentation

Documentation issues or improvement ideas

Feature Requests

Security feature requests and enhancements

Configuration Help

Ask the community for guidance

General Issues

Bug reports and general issues
Examples of non-vulnerability security concerns:
  • Suggestions for better default configuration values
  • Security hardening recommendations
  • Deployment best practices guidance
  • Unclear configuration instructions
  • Need for additional security documentation
  • Feature requests for optional security enhancements (2FA, audit logging, etc.)
  • General security questions about production deployment

​
Security Audits

We regularly audit our internal processes and system architecture for vulnerabilities using a combination of automated and manual testing techniques. We are also planning to implement SAST and SCA scans in our project.

​
Enterprise Security

For enterprise deployments requiring enhanced security features:

Enterprise Plan

Get custom theming, SLA support, and Long-Term Support (LTS) versions
Last updated: 2026-02-25

Build docs developers (and LLMs) love

Get started for freeTalk to us