> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/open-webui/open-webui/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Best Practices

> Security guidelines and vulnerability reporting for Open WebUI

## Security Overview

Our primary goal is to ensure the protection and confidentiality of sensitive data stored by users on Open WebUI.

<Info>
  Open WebUI is designed as a self-hosted, authenticated platform with extensible role-based access control architecture.
</Info>

## Supported Versions

| Version (Branch) | Supported       |
| ---------------- | --------------- |
| main             | ✅ Supported     |
| dev              | ❌ Not Supported |
| others           | ❌ Not Supported |

<Warning>
  Only the `main` branch receives security updates. The `dev` branch and other branches are not supported for security fixes.
</Warning>

## Security Best Practices

### Authentication & Access Control

<Tip>
  **Enable Strong Authentication**

  Open 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.
</Tip>

**Role-Based Access Control (RBAC)**

<Steps>
  <Step title="Create User Roles">
    Define detailed user roles with specific permissions for different user groups.
  </Step>

  <Step title="Restrict Model Access">
    Use RBAC to ensure only authorized individuals can access specific models.
  </Step>

  <Step title="Control Creation Rights">
    Reserve model creation and pulling rights for administrators only.
  </Step>
</Steps>

### Deployment Security

<Warning>
  **Data Persistence**

  Always mount a volume for data persistence:

  ```bash theme={null}
  -v open-webui:/app/backend/data
  ```

  This prevents data loss and ensures your database is properly secured.
</Warning>

**Database Security**

<Tip>
  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.
</Tip>

**Network Security**

```bash theme={null}
# 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
```

<Info>
  The backend reverse proxy design prevents direct exposure of the Ollama API to the frontend, safeguarding against CORS issues and unauthorized access.
</Info>

### Monitoring & Observability

**Enable Logging**

<Tip>
  For production environments, enable JSON-formatted logging for log aggregators:

  ```bash theme={null}
  -e LOG_FORMAT=json
  ```

  This makes logs suitable for tools like Loki, Fluentd, CloudWatch, and Datadog.
</Tip>

**Audit Logging**

Enable audit logs to track user actions:

```bash theme={null}
-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

<Warning>
  **Sensitive Environment Variables**

  Never commit files containing sensitive information:

  * `.env` files
  * `credentials.json`
  * API keys
  * OAuth secrets

  Use environment variables or secrets management solutions instead.
</Warning>

**Default Configuration Testing**

<Tip>
  Test your deployment with default security settings enabled. Only weaken security settings if absolutely necessary and document the reasons.
</Tip>

### Function & Tool Security

**Admin Control**

<Warning>
  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.
</Warning>

**Automatic Dependency Installation**

<Tip>
  For tighter control over function dependencies, disable automatic pip package installation:

  ```bash theme={null}
  -e ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS=false
  ```
</Tip>

## Reporting a Vulnerability

### Requirements for Valid Reports

<Warning>
  Before submitting a vulnerability report, ensure it meets ALL of the following requirements:
</Warning>

<AccordionGroup>
  <Accordion title="1. Must Be a Real Vulnerability">
    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.
  </Accordion>

  <Accordion title="2. No Vague Reports">
    Submissions such as "I found a vulnerability" without details will be treated as spam and rejected.
  </Accordion>

  <Accordion title="3. In-Depth Understanding Required">
    Reports must reflect a clear understanding of:

    * The codebase
    * How Open WebUI is used
    * Specific details about the vulnerability
    * Affected components
    * Potential impacts
  </Accordion>

  <Accordion title="4. Proof of Concept (PoC) is Mandatory">
    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.
  </Accordion>

  <Accordion title="5. Remediation Required">
    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
  </Accordion>

  <Accordion title="6. Default Configuration Testing">
    All vulnerability reports must be tested using Open WebUI's default configuration. Claims that only work with weakened security settings may be discarded.
  </Accordion>

  <Accordion title="7. Threat Model Understanding">
    Reports must demonstrate understanding of Open WebUI's self-hosted, authenticated, role-based access control architecture.
  </Accordion>

  <Accordion title="8. CVSS Scoring Accuracy">
    If you include a CVSS score, it must accurately reflect the vulnerability. Intentionally inflated scores may result in report rejection.
  </Accordion>

  <Accordion title="9. Admin Actions Are Out of Scope">
    Vulnerabilities requiring an administrator to actively perform unsafe actions are NOT valid. Admins have full system control and are expected to understand security implications.
  </Accordion>

  <Accordion title="10. AI Report Transparency">
    You MUST DISCLOSE if AI was used in any capacity - whether for writing the report, generating the PoC, or identifying the vulnerability.
  </Accordion>
</AccordionGroup>

### Where to Report

<Card title="Report a Vulnerability" icon="shield" href="https://github.com/open-webui/open-webui/security/advisories/new">
  Open a vulnerability report on GitHub Security Advisories
</Card>

<Warning>
  **Zero Tolerance for External Platforms**

  We 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.
</Warning>

## Non-Vulnerability Security Concerns

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

<CardGroup cols={2}>
  <Card title="Documentation" icon="book" href="https://github.com/open-webui/docs">
    Documentation issues or improvement ideas
  </Card>

  <Card title="Feature Requests" icon="lightbulb" href="https://github.com/open-webui/open-webui/discussions/">
    Security feature requests and enhancements
  </Card>

  <Card title="Configuration Help" icon="discord" href="https://discord.gg/5rJgQTnV4s">
    Ask the community for guidance
  </Card>

  <Card title="General Issues" icon="github" href="https://github.com/open-webui/open-webui/issues">
    Bug reports and general issues
  </Card>
</CardGroup>

**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

<Info>
  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.
</Info>

## Enterprise Security

For enterprise deployments requiring enhanced security features:

<Card title="Enterprise Plan" icon="building" href="https://docs.openwebui.com/enterprise">
  Get custom theming, SLA support, and Long-Term Support (LTS) versions
</Card>

***

*Last updated: 2026-02-25*