Security

Understanding the security risks in the bingo charm, and following the accompanying best practices, helps you protect your deployment against data loss, unauthorized access to pastes, and service disruption.

Outdated software

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

Best practices

  • Regularly update the charm revision to include the latest charm components. Updates include security fixes from the dependencies and the workload, as the charm dependencies are regularly updated.

  • Regularly update Juju to the latest version to include security fixes.

  • Deploy observability, like the Canonical Observability Stack, to detect any unusual behaviors.

Loss of data

Pastes live only in PostgreSQL: bingo has no S3 or other object storage option, so any loss or corruption of the database results in permanent loss of all pastes.

Best practices

  • Use a dedicated Charmed PostgreSQL deployment and regularly back up the database through the charm’s backup action.

Denial-of-service (DOS) attacks

Malicious attackers can overwhelm bingo with requests, making the application unresponsive to legitimate users. bingo has no built-in rate limiting; it relies entirely on the surrounding infrastructure to control request volume.

Best practices

  • Deploy an ingress that can limit the number of requests from users, such as Traefik or HAProxy, and configure request-rate throttling there.

  • Set the max-paste-size-bytes configuration to bound the resource cost of a single paste. This limits per-paste resource use, but does not address request volume.

Unencrypted traffic

bingo does not terminate TLS itself: it always serves plain HTTP and relies entirely on the charm’s ingress integration (Traefik) to provide encryption. Unless TLS is terminated at the ingress, traffic between bingo and its clients is unencrypted, risking eavesdropping and tampering.

bingo’s session and CSRF cookies are always set with Secure: true, so browsers silently drop these cookies over plain HTTP and authentication breaks without any visible error.

Best practices

  • Terminate TLS at the ingress, for example by integrating Traefik with a TLS provider or cert-manager. This is required both for usability and to protect session cookies from interception.

Confidentiality of pastes

Confidentiality of pastes relies on OIDC authentication (when configured) and link secrecy.

  • Without OIDC configured, there is no authentication at all: anyone who can reach bingo can create or read any paste. All pastes created this way are anonymous (no owner), so none of them can be explicitly deleted; they are only removed once they expire.

  • With OIDC enabled, the entire application is gated behind login, so only authenticated users can reach it. Any authenticated user with access to a paste’s key can view that paste. Confidentiality among authenticated users still depends on keeping paste links secret.

Best practices

  • Enable OIDC authentication to restrict who can reach bingo.

  • Recommend short expiry values (1d or 1w) over long-lived ones (1y) when creating pastes, since paste services routinely receive accidentally shared secrets or credentials.

  • Authenticated paste owners should delete their own pastes once they are no longer needed, rather than waiting for expiry.

Secret key hygiene

bingo’s shared application secret key signs OIDC session cookies. A leaked or long-lived secret key allows an attacker to forge valid session cookies.

Best practices

  • Rotate the secret key immediately if a breach is suspected, in addition to following routine credential-hygiene practices.