Skip to main content
Security is paramount in Bitwarden Server. This guide outlines security considerations for contributors and developers.

Reporting Security Vulnerabilities

DO NOT create public GitHub issues for security vulnerabilities.
Bitwarden has a responsible disclosure policy:

HackerOne Program

Report security vulnerabilities through Bitwarden’s HackerOne program: hackerone.com/bitwarden Bitwarden welcomes security researchers and offers rewards for valid findings.

Private Disclosure

For sensitive reports, you can:
  1. Encrypt your report using the PGP key:
    • Key ID: 0xDE6887086F892325FEC04CC0D847525B6931381F
    • Available in public keyserver pools
  2. Contact Bitwarden at https://bitwarden.com/contact

What NOT to Do

  • Denial of service attacks against production systems
  • Spamming users or systems
  • Social engineering of Bitwarden staff
  • Physical attempts against Bitwarden property or data centers

Security Disclosure Policy

From SECURITY.md:
  • Report vulnerabilities as soon as possible
  • Bitwarden will make every effort to quickly resolve issues
  • Provide reasonable time before public disclosure
  • Avoid privacy violations, data destruction, or service degradation
  • Only interact with accounts you own or have explicit permission to test

Secure Coding Practices

Never Commit Secrets

NEVER commit:
  • API keys or tokens
  • Passwords or connection strings with credentials
  • Private keys or certificates
  • .env files with real secrets
  • secrets.json with production values
Use placeholders instead:
secrets.json.example

Authentication & Authorization

Check Authorization

Always verify user permissions:

Use Policy-Based Authorization

Validate User Context

Input Validation

Validate All Inputs

Use Data Annotations

Prevent Injection Attacks

SQL Injection - Use parameterized queries:

Password Handling

Client-Side Hashing

Bitwarden uses client-side password hashing:
Key Points:
  • Client sends PBKDF2(password, email)
  • Server stores PBKDF2(clientHash, email) (double-hashed)
  • Server never sees the actual password

Never Log Passwords

Cryptography

Don’t Roll Your Own Crypto

Use established libraries:

Use Strong Random Numbers

Proper Key Derivation

Data Protection

Protect Sensitive Data at Rest

Use ASP.NET Core Data Protection:

Protect Secrets in Configuration

API Security

Rate Limiting

CORS Configuration

HTTPS Enforcement

Error Handling

Don’t Leak Information

Log Errors Securely

Session Management

Secure Session Tokens

Implement Logout

Security Testing

Write Security Tests

Test Authorization

Dependency Security

Keep Dependencies Updated

Review Dependencies

Before adding new dependencies:
  1. Check package popularity and maintenance
  2. Review recent security advisories
  3. Verify package signatures
  4. Review license compatibility

Production Security

Environment Variables

Never hardcode production values:

Secrets Management

Use proper secrets management:
  • Development: User Secrets, .env files (not committed)
  • Production: Azure Key Vault, AWS Secrets Manager, etc.

Security Headers

Security Checklist

Before submitting security-sensitive code:
  • All user inputs are validated
  • Authentication checks are in place
  • Authorization is verified
  • No secrets in code or commits
  • Parameterized queries used (no SQL injection)
  • Sensitive data is encrypted
  • Error messages don’t leak information
  • Security tests added
  • Dependencies are up to date
  • Code reviewed for security issues

Resources

See Also