Context
Problem Statement:
The HDIM healthcare platform had hardcoded credentials throughout the codebase, creating critical security vulnerabilities:
auth.interceptor.ts contained hardcoded Basic Auth credentialsapplication.yml files had default passwords like dev_password, healthdata_passwordchangeme_in_production.env files with real credentials were at risk of being committedBusiness Context:
Technical Context:
Decision
We will externalize all secrets and credentials to environment variables with no insecure defaults.
Specific Implementation:
- Remove hardcoded Basic Auth from auth.interceptor.ts
- Use JWT Bearer tokens from AuthService
- Never store credentials in frontend code
- All passwords use ${ENV_VAR:} pattern (empty default)
- JWT secrets require explicit configuration
- Service-to-service auth via environment variables
- .env.example as template with CHANGE_ME placeholders
- .gitignore excludes all .env* files except .env.example
- Security warnings in YAML comments
Alternatives Considered
Alternative 1: Continue with Development Defaults
Description: Keep dev_password defaults for developer convenience
Pros:
Cons:
Why Not Chosen: Unacceptable security risk for healthcare platform
Alternative 2: Encrypted Properties Files
Description: Use Jasypt or similar to encrypt properties
Pros:
Cons:
Why Not Chosen: Shifts problem to encryption key management
Alternative 3: Spring Cloud Config Server
Description: Centralized configuration server
Pros:
Cons:
Why Not Chosen: Environment variables simpler for initial fix; Vault added in ADR-0004
Consequences
Positive Consequences
Negative Consequences
Mitigation
.env.example with all required variablesopenssl rand commands in comments for generating secretsCompliance & Security
Implementation Plan
.gitignore and .env.example updatesFiles Modified
apps/clinical-portal/src/app/interceptors/auth.interceptor.tsbackend/modules/services/*/src/main/resources/application.yml (16+ files).gitignore.env.example