Backup credentials stored in the same secrets store as primary credentials collapse the security boundary between your production system and your recovery system. If primary credentials are compromised, the attacker also has the backup credentials — and the backup process may have elevated permissions to access data that the primary application cannot touch. NIST CP-9 requires protecting backup data with the same rigor as the primary system. CWE-522 applies when backup credentials are insufficiently protected. Over-broad backup credentials also create a data exfiltration vector: an attacker with backup access can pull a full database dump without triggering normal access controls.
Low because backup credentials stored alongside primary credentials eliminate the security isolation that makes a separate backup process valuable during a breach or insider threat scenario.
Store backup credentials in a separate secrets path or vault namespace with explicitly restricted permissions. Backup accounts should have read-only or restore-only access — they must not be able to drop tables, alter schemas, or modify production data.
// Retrieve from separate secrets paths
const primaryDb = await secretsClient.get('prod/primary/db-credentials')
const backupDb = await secretsClient.get('prod/backup/db-credentials') // separate path
// AWS IAM: backup role policy (restore-only)
// Allow: rds:RestoreDBInstanceFromDBSnapshot
// Allow: rds:DescribeDBSnapshots
// Deny: rds:DeleteDBInstance, rds:ModifyDBInstance
Document which team members have access to backup credentials separately from who has access to primary credentials. Audit access quarterly and revoke permissions for anyone not actively responsible for disaster recovery.
ID: environment-security.configuration-security.backup-credentials
Severity: low
What to look for: Check for backup and disaster recovery configuration. If backup credentials are present, verify they are stored separately from primary credentials with limited permissions.
Pass criteria: Count all backup credential sets found. Backup credentials (e.g., database backup credentials) are stored separately from primary credentials with at least 100% using backup-only permissions (cannot access primary resources).
Fail criteria: Backup credentials stored alongside primary credentials, or backup credentials have overly broad permissions.
Skip (N/A) when: The project does not have backup/restore functionality or does not require separate backup credentials.
Detail on fail: "Database backup credentials stored in same secrets manager as production credentials with full access permissions".
Remediation: Use a separate backup secrets store:
// Primary credentials
const primaryDB = process.env.PRIMARY_DATABASE_URL
// Backup credentials (separate location, limited permissions)
const backupDB = process.env.BACKUP_DATABASE_URL
// Backup account can only: RESTORE, not DROP or ALTER
// Or in AWS:
// Primary: IAM user with full database access
// Backup: IAM user with backup-only role (backup:* permissions only)