Skip to content

CWE-530: Exposure of Backup File to an Unauthorized Control Sphere

Overview

Backup file exposure occurs when backup, temporary, editor swap, archive, or old deployment files are left in a location that unauthorized users can access. These files often bypass normal application routing and access control because the web server serves them as static files.

Examples include .bak, .old, .orig, ~, .swp, .tmp, .zip, .tar.gz, copied configuration files, exported databases, and backup copies of source files such as index.php.bak. These files can reveal source code, credentials, database connection strings, internal paths, API keys, comments, or previous versions of sensitive logic.

OWASP Classification

Not Mapped to OWASP Top 10 2025

Risk

Medium to High: Exposed backup files can disclose secrets and implementation details that attackers use to compromise the application. A single backup of a configuration file may contain database credentials, signing keys, cloud tokens, or administrative endpoints. A backup of source code can reveal vulnerabilities, hidden routes, authorization logic, or hardcoded credentials.

Remediation Steps

Core principle: Never place backup or temporary files inside a public web root or object storage prefix; block access to backup extensions and remove these files during deployment.

Remove Backup and Temporary Files Before Deployment

# Run from the release artifact or staging directory before publishing
find . -name "*.bak" -delete
find . -name "*.old" -delete
find . -name "*.orig" -delete
find . -name "*~" -delete
find . -name "*.swp" -delete
find . -name "*.tmp" -delete
find . -name ".DS_Store" -delete

Treat this as a build or release step, not a manual cleanup task.

Keep Backups Outside the Web Root

Store backups in locations that are not served by the web server:

  • Dedicated backup storage with access control
  • Private object storage buckets
  • Encrypted backup repositories
  • Infrastructure-managed snapshots
  • Directories outside /var/www, public/, htdocs/, or equivalent web roots

Backups should have separate retention, access logging, and encryption policies.

Configure Web Server Deny Rules

Apache:

<FilesMatch "(\.bak|\.old|\.orig|\.save|\.swp|\.tmp|~|\.zip|\.tar|\.tar\.gz)$">
    Require all denied
</FilesMatch>

Nginx:

location ~* (\.bak|\.old|\.orig|\.save|\.swp|\.tmp|~|\.zip|\.tar|\.tar\.gz)$ {
    deny all;
}

These rules are defense in depth. They should not be the only control because a missing extension or new backup convention can bypass them.

Exclude Development Artifacts From Release Packages

Use packaging rules that include only the files required to run the application. Exclude:

  • Backup and editor-generated files
  • .git, .svn, .hg, and other version control directories
  • .env, local config, and secrets files
  • Test databases and local exports
  • Build caches and temporary directories

Container builds should copy only compiled or runtime artifacts into the final image.

FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:18-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/server.js"]

Scan for Exposed Backup Files

Regularly check production and staging for common backup names:

  • /index.php.bak
  • /config.php~
  • /.env.old
  • /database.sql
  • /backup.zip
  • /www.tar.gz
  • /web.config.orig

Automated checks should run after deployment and against public endpoints, not only inside the repository.

Additional Resources