No Backup Policy
Without regular tested backups, a ransomware attack, accidental deletion, or database corruption can result in permanent data loss.
How It Works
Ransomware groups specifically target databases and cloud storage. Without backups — or with backups that are stored in the same account as the primary data — a single compromise can encrypt or delete everything. Even without an attack, database corruption and accidental deletions happen. The question is not if, but when.
// BAD: no backup configuration — Supabase project with no point-in-time recovery
// or database with manual dumps that were never actually tested
// or backups stored in the same AWS account as production data// GOOD: automated backups with tested restore procedures
// For Supabase: enable Point-in-Time Recovery (Pro plan)
// For self-hosted Postgres: pg_dump to separate S3 bucket in different account
// .github/workflows/backup.yml — scheduled daily
// Verify restores monthly: actually restore to a test environment and confirm data integrityReal-World Example
GitLab's 2017 incident: a sysadmin accidentally deleted the wrong database directory during a failover procedure. Six hours of production data were lost because none of the five backup methods were actually working correctly at the time.
How to Prevent It
- Enable automated daily backups for your database — Supabase Pro, RDS automated backups, or a cron-based pg_dump
- Store backups in a separate account or cloud provider from your production data
- Test your restore process quarterly — a backup you've never restored from is not a backup
- Set a Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and verify your backups meet them
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
NODE_ENV Not Set to Production
mediumRunning Node.js without NODE_ENV=production enables verbose error messages, disables caching optimizations, and can activate development-only middleware.
Debug Mode Active in Production
mediumDebug mode enabled in production exposes internal state, enables verbose logging, and sometimes activates interactive debugging endpoints that attackers can exploit.
No Health Check Endpoint
lowWithout a /health endpoint, load balancers and orchestrators can't verify your application is actually working before routing traffic to it.
No Error Monitoring
lowWithout error monitoring, production errors are invisible until a user reports them — which most never do.