As I continue learning web application security, I keep discovering that many serious vulnerabilities don't require sophisticated hacking techniques.
Sometimes, attackers don't need SQL Injection.
Sometimes, they don't need Remote Code Execution.
Sometimes, they simply download a file that was never supposed to be public.
One of the most common examples is exposed backup files.
In this article, we'll explore how backup files can accidentally expose an application's source code and why developers should never leave them on production servers.
Why This Matters
Imagine you've spent months developing a web application.
Your source code contains:
- Authentication logic
- Database connections
- API integrations
- Business logic
- Security controls
Now imagine all of that becomes publicly downloadable because of a forgotten backup file.
That's exactly what happens in many source code disclosure incidents.
A single exposed file can give attackers a blueprint of your entire application.
What Are Backup Files?
Developers often create backups before making changes.
Examples include:
login.php.bak
index.php.old
config.php.backup
website.zip
source.rar
app.tar.gz
These files are useful during development.
The problem starts when they accidentally remain on a production server.
How Attackers Find Backup Files
Attackers rarely guess vulnerabilities manually.
Instead, they automate the process.
Common filenames they look for:
index.php.bak
login.php.old
config.php.bak
web.config.bak
backup.zip
source.zip
site_backup.tar.gz
Many scanners automatically test hundreds of common backup file names.
Simple example:
Normal page:
https://example.com/login.php
Possible backup:
https://example.com/login.php.bak
If the server allows access, the attacker downloads the file.
Understanding Source Code Disclosure
Normally, when a PHP page is requested:
login.php
The server executes the code and only returns the output.
Example:
<?php
echo "Welcome";
?>
Browser receives:
Welcome
However, a backup file is often treated as a normal downloadable file.
Example:
login.php.bak
Instead of executing the code, the server sends the file contents directly.
The attacker now sees:
<?php
$db_user = "admin";
$db_pass = "password123";
$query = "SELECT * FROM users WHERE username='$user'";
?>
The application's internal logic is exposed.
Real-World Risks
1. Database Credentials Exposure
Developers often store database settings in configuration files.
Example:
$db_host = "localhost";
$db_user = "root";
$db_pass = "SuperSecretPassword";
An exposed backup file may reveal these credentials immediately.
2. Hidden Admin Panels
Source code often reveals endpoints that are not publicly linked.
Example:
/admin
/internal-dashboard
/debug-panel
Attackers can directly access these locations.
3. Hardcoded API Keys
Developers sometimes accidentally store:
AWS Keys
Stripe Keys
SMTP Credentials
JWT Secrets
inside source code.
These become visible once the code is exposed.
4. Easier Vulnerability Discovery
With source code available, attackers can analyze:
Authentication logic
Input validation
Database queries
File uploads
Access controls
Finding vulnerabilities becomes much easier.
Visualizing the Attack
Developer
│
▼
Creates backup file
login.php.bak
│
▼
Uploads to production
│
▼
Attacker discovers file
│
▼
Downloads source code
│
▼
Finds secrets and vulnerabilities
Practical Example
Imagine a website contains:
https://example.com/login.php
A backup file exists:
https://example.com/login.php.bak
An attacker downloads it and discovers:
$query = "SELECT * FROM users
WHERE username='$user'
AND password='$pass'";
The attacker notices user input is directly inserted into the query.
This immediately suggests a potential SQL Injection vulnerability.
Without source code, finding this issue could take much longer.
With source code, it becomes obvious.
Common Mistakes Developers Make
| Mistake | Risk |
|---|---|
| Uploading .bak files | Source code exposure |
| Leaving ZIP backups online | Entire application disclosure |
| Storing secrets in code | Credential leakage |
| No deployment review process | Sensitive files remain public |
| No security scanning | Vulnerabilities go unnoticed |
Best Practices
Use Version Control
Instead of storing backups on servers:
Git
GitHub
GitLab
Bitbucket
provide safer version history management.
Separate Backups from Web Root
Bad:
/var/www/html/backup.zip
Better:
/opt/backups/
outside the web-accessible directory.
Remove Temporary Files Before Deployment
Create deployment checklists that verify:
No .bak files
No .old files
No ZIP archives
No test files
Scan Production Servers
Regularly search for:
*.bak
*.old
*.zip
*.tar.gz
before releases.
Store Secrets Securely
Avoid:
$password = "SuperSecretPassword";
Use:
Environment Variables
Secret Managers
Vault Solutions
instead.
Key Takeaways
- Backup files often contain complete source code.
- Source code disclosure can reveal credentials and sensitive information.
- Attackers actively search for backup files.
- A single exposed file can compromise an entire application.
- Proper deployment practices significantly reduce risk.
Conclusion
When learning cybersecurity, it's easy to focus on advanced attacks like SQL Injection, Remote Code Execution, or privilege escalation.
However, many real-world breaches begin with something much simpler.
A forgotten backup file.
Security isn't only about preventing attackers from breaking in.
It's also about avoiding mistakes that accidentally invite them in.
Before deploying any application, make sure backup files, temporary files, and old versions never reach your production server.
That small habit can prevent a major security incident.
Top comments (2)
Review one of your projects today and check whether any backup or temporary files are accessible from the web.
If you're also learning cybersecurity, follow my journey as I explore real-world vulnerabilities and security concepts one topic at a time.