Security

This document explains the possible security risks in the Discourse charm and best practices to avoid them. It revolves around the practices from the charm side. Refer to the official Discourse documentation for upstream practices.

Outdated software

Outdated software components, such as plugins or the upstream workload, can introduce exploitable security vulnerabilities.

Best practices

• Regularly update the charm revision to include latest charm components. Updates include the security fixes from the dependencies and the workloads as the charm dependencies are regularly updated.
• Regularly update Juju to latest version to include security fixes.
• Deploy observability, like the Canonical Observability Stack, to detect any unusual behaviors.

Loss of data

The Discourse database or the media files can be lost or corrupted for various reasons.

Best practices

• Use S3 for uploads and regular backups. See how to configure S3 section.
• Use a dedicated Charmed PostgreSQL and regularly back up the database through the charm’s backup action.

Denial-of-service (DOS) attacks

Malicious attackers can overwhelm the Discourse traffic with DOS attacks, making the application unresponsive to legitimate users.

Best practices

• Deploy an ingress that can limit the number of requests per users. For example, NGINX Ingress Integrator charm supports limiting the requests per second through limit-rps configuration and features an allow list through limit-whitelist configuration.
• Set the throttle level directly from Discourse charm through the throttle-level configuration by setting it to permissive or strict.

Unencrypted traffic

If Discourse serves HTTP, the traffic between Discourse and the clients will be unencrypted, risking eavesdropping and tampering.

Best practices

• Always enable HTTPS by setting the force_https configuration option to True.
• Integrate the Discourse charm with an ingress that provides TLS, such as NGINX Ingress Integrator.
• Force SMTP encryption by setting smtp_force_tls to True.

Cross-origin requests (CORS)

Discourse can be configured to enable or disable CORS through the enable_cors configuration option. If enabled unnecessarily or cors_origin is configured too broadly, a malicious attacker can interact with Discourse on behalf of legitimate users.

Best practices

• Only set enable_cors if you require Single Sign-On (SSO) or another trusted cross-domain integration.
• Only allow trusted origins by configuring the cors_origin and augment_cors_origin options. Do not set cors_origin to * as this allows all origins.