Data Encryption

Munera encrypts sensitive data both in transit and at rest using industry-standard algorithms.

Encryption in transit

All communication between clients and Munera is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled. On munera.cloud, our Nginx configuration enforces HSTS with a 1-year max-age and includes the includeSubDomains directive.

Encryption at rest

Data typeAlgorithmNotes
PasswordsArgon2idMemory-hard, GPU-resistant. Industry standard as of 2025.
API keysArgon2idOnly the hash is stored. Plaintext is shown once at creation.
Integration tokens (Slack, Jira, GitHub)AES-256 (Fernet)Symmetric encryption using the ENCRYPTION_KEY secret.
SSO secretsAES-256 (Fernet)Same as above.
General database contentNot encrypted at field levelRelies on database-level and disk-level encryption on the host.

Security headers

Munera sets the following HTTP security headers on all responses:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; ...
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Multi-tenancy data isolation

Munera is a multi-tenant platform. Data isolation is enforced at the application layer — every database query includes an organisation_id filter applied by the ORM's repository layer. It is not possible for one organisation's requests to return another organisation's data, regardless of what IDs are passed in the request.

Key management (self-hosted)

For self-hosted deployments, you are responsible for managing your SECRET_KEY and ENCRYPTION_KEY. Best practices:

  • Never commit secrets to version control
  • Store .env.production with chmod 600
  • Rotate keys every 90 days (note: rotating SECRET_KEY invalidates all active sessions)
  • Consider using a secrets manager like AWS Secrets Manager or HashiCorp Vault for production deployments