Files
wg-portal/docs/documentation/usage/security.md
Mykhailo Roit 958dcb8fa9 feat: sanitize external identity provider user data (#681)
* feat: sanitize external user data

* remove config option to disable Sanitization: sanitize_external_user_data

* cleanup

---------

Co-authored-by: Christoph Haas <christoph.h@sprinternet.at>
2026-05-18 22:28:27 +02:00

3.4 KiB
Raw Permalink Blame History

This section describes the security features available to administrators for hardening WireGuard Portal and protecting its data.

Database Encryption

WireGuard Portal supports multiple database backends. To reduce the risk of data exposure, sensitive information stored in the database can be encrypted. To enable encryption, set the encryption_passphrase in the database configuration section.

⚠️ Important: Once encryption is enabled, it cannot be disabled, and the passphrase cannot be changed! Only new or updated records will be encrypted; existing data remains in plaintext until its next modified.

External Identity Provider Data Sanitization

When users authenticate via LDAP, OIDC, or OAuth, WireGuard Portal sanitizes the field values received from the provider before storing them. This protects against several classes of attack that a compromised or misconfigured identity provider could introduce:

  • Unsafe control characters — Unicode control and format characters, null bytes, and invalid UTF-8 bytes are stripped from external profile fields before they reach the Vue.js UI or email templates.
  • Email header injection — carriage return and line feed characters in email fields are rejected entirely, and email fields must parse as plain email addresses.
  • Log injection — unsafe control and format characters are stripped from all external profile fields and from sanitization log context.
  • Denial of service via oversized fields — field lengths are capped (e.g., 256 runes for identifiers, 254 characters for email addresses).
  • Reserved identifier collision — reserved user identifiers such as "all", "new", "id", and internal system user identifiers are rejected.
  • Unsafe authorization groups — OIDC/OAuth group claims are sanitized before group-based checks; groups changed by control/format stripping or truncation are dropped rather than repaired into allowed/admin matches.

Sanitization is always enabled and cannot be disabled.

When sanitization modifies or clears a field value, a WARN log entry is emitted with the provider name, provider type, and field name — but never the raw or sanitized value, to avoid leaking sensitive data into logs. This makes it straightforward to detect and investigate potentially malicious or misconfigured providers.


UI and API Access

WireGuard Portal provides a web UI and a REST API for user interaction. It is important to secure these interfaces to prevent unauthorized access and data breaches.

HTTPS

It is recommended to use HTTPS for all communication with the portal to prevent eavesdropping.

Event though, WireGuard Portal supports HTTPS out of the box, it is recommended to use a reverse proxy like Nginx or Traefik to handle SSL termination and other security features. A detailed explanation is available in the Reverse Proxy section.

Secure Authentication

To prevent unauthorized access, WireGuard Portal supports integrating with secure authentication providers such as LDAP, OAuth2, or Passkeys, see Authentication for more details. When possible, use centralized authentication and enforce multi-factor authentication (MFA) at the provider level for enhanced account security. For local accounts, administrators should enforce strong password requirements.