Open WebUI Security: Hardening Auth, RBAC, Tools and Exposure

Open WebUI is often the first thing a team deploys in front of a local or hosted model, and several of its defaults assume a private, trusted network: CORS open to any origin, four-week login tokens, no audit log, code execution switched on and Tools and Functions that run arbitrary Python on the server. Put one on the internet unchanged and a chat interface becomes a code execution and credential store with a login page. This guide covers how to harden an Open WebUI deployment: authentication and SSO, roles and additive group permissions, the risk model for Tools, Functions, tool servers and code execution, API keys and stored provider keys, audit logging and the network placement the project itself recommends. It is for platform, security and AI engineering teams running Open WebUI for more than a handful of users. Model hosting and inference servers are covered in the Self-Hosted LLM Security Guide; this page is about the front end. Settings and defaults are from Open WebUI's official documentation, checked 8 November 2026; the project releases often, so confirm names against the documentation for your version.

This is an independent guide from NHI Mgmt Group, based on Open WebUI's public documentation as of November 2026. It is not sponsored or reviewed by Open WebUI. Product features change, so confirm settings against Open WebUI's current documentation.

Key takeaways

• Keep it off the open internet. The project says Open WebUI is built for private, trusted networks and recommends a VPN, a zero-trust access proxy or an authenticating reverse proxy in front of it.
• Tools and Functions are server-side code. Anyone who can create or import them has the same access as the Open WebUI process: files, network, environment variables and the database. Keep that permission admin-only, or switch the feature off.
• Admins see everything and permissions only add. The admin role bypasses granular permissions, group permissions are a union with no deny, and hiding chats from admins does not remove their access to the data.
• Several defaults need changing for production. Restrict CORS_ALLOW_ORIGIN, shorten JWT_EXPIRES_IN or deploy Redis for revocation, set secure cookies and security headers, and turn on audit logging.
• It holds valuable non-human credentials. Admin-configured provider keys, user API keys, the SCIM token and WEBUI_SECRET_KEY all need inventory, scoping and rotation.

How identity and access work in Open WebUI

Open WebUI's documented threat model is a self-hosted, single-tenant, authenticated, role-based application in which administrators are trusted actors with full control. Every user must sign in; the first account created on a fresh install becomes the administrator and sign-up is then closed automatically. New accounts default to the pending role, which has no access until an admin approves it.

Account merging: OAUTH_MERGE_ACCOUNTS_BY_EMAIL joins an OAuth login to an existing local account with the same email. The documentation says this is not recommended and can lead to account takeover if the provider does not reliably verify email addresses. Keep it false.

Sessions: login tokens are JWTs signed with WEBUI_SECRET_KEY, valid for four weeks by default (JWT_EXPIRES_IN=4w; -1 disables expiry). Without Redis, signing out does not invalidate that session's token; a password change or an admin's Sign out all devices ends all of an account's sessions, but API keys stay valid. With Redis, revocation works per session and OIDC back-channel logout is supported, but the docs warn that revocation checks fail open when Redis is unreachable and log Revocation check failed; accepting token. Alert on that line. Cookie defaults are WEBUI_SESSION_COOKIE_SECURE=false and SAME_SITE=lax; behind HTTPS set them to true and strict. For the token theory see the JWT and Session Tokens in Logs Guide.

Admin roles and privileged access

• Additive groups: permissions are a union across all of a user's groups, subgroups inherit their parents' permissions, and there is no deny. Start restrictive at the default level and grant features through narrow "permission groups"; the project suggests separating permission groups from sharing groups by naming.
• Few admins: because admin implies arbitrary code (admins can install Functions), treat the role like root on the host. Map it from an IdP group with OAUTH_ADMIN_ROLES so it can be reviewed with other privileged access; see the Privileged Access Management Guide.
• Bootstrap safely: whoever registers first becomes admin. The project advises never exposing an unconfigured instance and, where it must be reachable immediately, creating the admin at startup with WEBUI_ADMIN_EMAIL and WEBUI_ADMIN_PASSWORD. Apply Open WebUI security updates promptly and follow the project's security policy for advisories.
• Workspace permissions: USER_PERMISSIONS_WORKSPACE_MODELS_ACCESS, _KNOWLEDGE_ACCESS, _TOOLS_ACCESS, _TOOLS_IMPORT and _PROMPTS_ACCESS all default to false. Granting tools access to a group gives that group server-level code execution.

Integrations, API tokens and service accounts

Tools, Functions, tool servers and code execution

The security policy is explicit: Tools, Functions and Pipelines execute arbitrary Python with the same access as the backend, by design, and reports about that behaviour are out of scope. The risk is therefore about who can install them and what they pull in, which maps to OWASP LLM03:2025 Supply Chain and LLM06:2025 Excessive Agency.

Only install Tools and Functions from sources you have reviewed; read the code the way you would review a pull request that runs as the service account. MCP and OpenAPI tool servers extend the same trust to remote services: see the AI Agent Tool and Plugin Security Guide and the MCP Security Guide. Model output that triggers tools is also an injection path, covered in the Prompt Injection Guide.

API keys and provider credentials

• User API keys carry the same permissions as the user who created them. By default only admins can create them; USER_PERMISSIONS_FEATURES_API_KEYS=true extends that to users. Limit what a key can call with ENABLE_API_KEYS_ENDPOINT_RESTRICTIONS=true and API_KEYS_ALLOWED_ENDPOINTS (for example only /api/chat/completions and /api/v1/models). Issue keys to named service users, not to admins.
• Admin-configured provider keys for OpenAI-compatible and other upstreams are used on every user's behalf. Keep ENABLE_OPENAI_API_PASSTHROUGH=false (the default): when enabled, any authenticated user can reach any upstream endpoint with the admin's key and without model access control. Use provider-side spend limits and project-scoped keys; see the LLMjacking Guide.
• Direct connections (ENABLE_DIRECT_CONNECTIONS, off by default) let users add their own provider keys, which are sent to the Open WebUI server. Any service that stores many provider keys becomes a target, so enable it only where you can protect and monitor the stored keys.
• WEBUI_SECRET_KEY signs every session. Set it explicitly (shared across replicas, generated with a strong random source), store it in a secrets manager, and note that the Docker image writes an auto-generated key to /app/backend/.webui_secret_key, outside the data directory. Rotating it signs everyone out.
• SCIM_TOKEN and database credentials are static; rotate them on a schedule and on staff changes. See the Secrets Management Guide.

Logging and detection

Audit logging is off by default (AUDIT_LOG_LEVEL=NONE). Set METADATA at minimum, which records user, IP address, user agent, method, URL, timestamp and requested model; REQUEST and REQUEST_RESPONSE add bodies up to MAX_BODY_LOG_SIZE (2,048 bytes by default) and will capture prompts, so treat those logs as sensitive data. Output goes to /app/backend/data/audit.log and optionally stdout (ENABLE_AUDIT_STDOUT). Note the gaps the docs list: the default exclusions skip /api/chat/completions (drop /chat from AUDIT_EXCLUDED_PATHS to record it), Socket.IO traffic is not covered, and sign-in, sign-out, sign-up and MFA endpoints are always audited with metadata only. Set FORWARDED_ALLOW_IPS to your proxy's address, otherwise any client can spoof the source IP in audit records. Use LOG_FORMAT=json for the SIEM.

Metrics: number of admins (and percentage mapped from the IdP); number of installed Tools and Functions with a recorded code review; count of active API keys and percentage with endpoint restrictions; days since the running version was released; percentage of audit records with a user attributed; mean time to remove a leaver's sessions and keys.

Hardening baseline

1. Place it privately: run behind a VPN, a zero-trust access proxy or an authenticating reverse proxy, which also terminates TLS (Open WebUI does not) and enforces rate limiting. Complete first-run setup before any exposure, or create the admin from environment variables.
2. Set the core environment: WEBUI_SECRET_KEY from a secrets manager, ENV=prod (disables the API docs at /docs; the Docker image sets it), CORS_ALLOW_ORIGIN to your own origin, secure and strict cookies, FORWARDED_ALLOW_IPS to the proxy.
3. Add security headers: none are set by default. Start with HSTS, XFRAME_OPTIONS=DENY, XCONTENT_TYPE=nosniff and a Content Security Policy tested first with CONTENT_SECURITY_POLICY_REPORT_ONLY. Consider IFRAME_CSP with connect-src 'none' so generated artifacts cannot exfiltrate data.
4. Move identity to SSO: OIDC with domain restriction and role mapping, then disable the login form and password auth; or enable MFA. Deploy Redis for revocation, or shorten JWT_EXPIRES_IN to hours.
5. Shrink the plugin surface: disable plugins or code execution you do not use, stop frontmatter pip installs, keep workspace tool permissions admin-only, and set ENABLE_COMMUNITY_SHARING=false to keep chats, models, prompts and tools on your instance.
6. Contain fetches and uploads: keep ENABLE_RAG_LOCAL_WEB_FETCH=false and AIOHTTP_CLIENT_ALLOW_REDIRECTS=false, extend WEB_FETCH_FILTER_LIST for internal ranges, set RAG_FILE_MAX_SIZE, RAG_FILE_MAX_COUNT and allowed extensions (no limits by default), and consider ENABLE_PROFILE_IMAGE_URL_FORWARDING=false.
7. Harden the container and data: build with a non-root UID and GID, use PostgreSQL on an internal network for production, put SQLite data on an encrypted filesystem (SQLCipher is not supported) and back up /app/backend/data.
8. Log and patch: enable audit logging to the SIEM, subscribe to the project's releases and security advisories, and upgrade all replicas together.

Rollback: keep the previous image tag and environment file; test SSO-only and header changes on a staging instance, and keep one break-glass local admin until SSO has run cleanly for a release cycle.

Common misconfigurations

• Publishing a fresh instance: whoever registers first becomes admin, and admin means server code execution.
• Trusted-header auth without header stripping: any client can forge the email header and sign in as anyone.
• Granting workspace tools access to a broad group: because permissions are additive, one group grant gives every member arbitrary Python on the server.
• Relying on sign-out without Redis: a stolen token stays valid for up to four weeks by default.
• Turning on OpenAI API passthrough: exposes every upstream endpoint with the admin's provider key.
• Leaving audit logging at NONE: no evidence of who installed a Function or used a key when something goes wrong.

Practitioner checklist

• Instance is reachable only through a VPN, zero-trust proxy or authenticating reverse proxy that terminates TLS.
• Admin was created privately or from environment variables; admins are few and mapped from an IdP group.
• SSO with role mapping is enforced, the login form and password auth are disabled, or MFA is on.
• Redis provides token revocation, or JWT_EXPIRES_IN is measured in hours.
• CORS_ALLOW_ORIGIN, secure strict cookies, FORWARDED_ALLOW_IPS and security headers are set.
• Unused plugins and code execution are disabled; frontmatter pip installs are off; tool permissions are admin-only.
• Every installed Tool and Function has a recorded code review and owner.
• API keys are endpoint-restricted, owned by named service users and rotated; passthrough is off.
• WEBUI_SECRET_KEY, SCIM_TOKEN and database credentials live in a secrets manager.
• Audit logging is at METADATA or above, includes chat completions if needed, and reaches the SIEM.

Standards and references

• Open WebUI: Hardening Open WebUI
• Open WebUI: Security Policy
• Open WebUI: Vendor Dispositions and Threat Model
• Open WebUI: Groups and Permissions
• Open WebUI: Environment Variable Configuration
• OWASP: Top 10 for LLM Applications 2025
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Self-Hosted LLM Security Guide · LLM Security Guide · AI Agent Tool and Plugin Security Guide · LLMjacking Guide