Critical Configjs Exposure: How A Simple Browser Request Can Hand Over Your Database To Attackers + Video

Introduction:

During a routine web application security test, a security researcher discovered a publicly accessible `config.js` file that exposed critical database credentials—host, username, and database name—directly through the browser. This type of sensitive file exposure occurs when developers mistakenly store configuration data on the client side, allowing attackers to map backend infrastructure and escalate privileges toward a full data breach. Understanding how to detect, mitigate, and prevent such exposures is essential for any AppSec or DevOps professional.

Learning Objectives:

Identify exposed sensitive configuration files (e.g., config.js, .env, settings.json) during security assessments.
Implement server‑side access controls (Apache, Nginx, IIS) to block direct access to client‑side configuration files.
Apply secure coding practices that move secrets out of frontend assets and into environment variables or secret managers.

Understanding the Vulnerability: How `config.js` Becomes a Threat

Developers often embed database connection strings, API keys, or internal hostnames into JavaScript files intended for client‑side use. If these files are placed inside the webroot (e.g., /js/config.js, /config.js), anyone can retrieve them by simply guessing the filename or using directory brute‑forcing tools.

Step‑by‑step guide for detection (ethical testing only):

Manual check – Open the browser’s developer tools, navigate to the “Sources” tab, and look for configuration files. Alternatively, directly request:
`https://target.com/config.js` or `https://target.com/js/app/config.js`

2. Using `curl` (Linux/macOS):

curl -I https://target.com/config.js  Check HTTP status (200 = exposed)
curl -s https://target.com/config.js | head -20

3. Using PowerShell (Windows):

Invoke-WebRequest -Uri "https://target.com/config.js" -Method Head
Invoke-WebRequest -Uri "https://target.com/config.js" | Select-Object -ExpandProperty Content

4. Automated discovery with `gobuster`:

gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt -x js,json

What this does: It enumerates web directories for files ending in `.js` or .json, revealing whether a `config.js` is publicly readable. Attackers then extract database host, username, and schema names to plan further attacks (e.g., SQL injection, credential stuffing).

Step‑by‑Step Guide to Secure Web Servers (Apache & Nginx)

Prevent direct HTTP access to configuration files while keeping them functional for your application’s internal logic.

Apache (.htaccess or httpd.conf)

Open your virtual host configuration or create an `.htaccess` file inside the webroot.

Add the following block to deny access to .js, .json, or `.env` files:

<FilesMatch "\.(js|json|env|config)$">
Require all denied
</FilesMatch>

If you need to block only a specific file:

<Files "config.js">
Require all denied
</Files>

4. Restart Apache: `sudo systemctl restart apache2`

Nginx

1. Edit the server block (e.g., `/etc/nginx/sites-available/default`).

Add a location directive to deny access to sensitive extensions:
```
location ~ .(js|json|env|config)$ {
deny all;
return 403;
}
```

3. Test the configuration: `sudo nginx -t`

4. Reload Nginx: `sudo systemctl reload nginx`

Windows IIS

1. Open IIS Manager, select your site.

2. Double‑click “Request Filtering”.

Under “File Name Extensions”, click “Deny Extension…” and add .js, .json, .config.

4. Alternatively, use `web.config`:

<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<add fileExtension=".js" allowed="false" />
<add fileExtension=".json" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>

Why this works: These rules block any HTTP request that directly targets configuration files, returning a `403 Forbidden` error while leaving the application’s internal file reads unaffected (if the app accesses them via the filesystem, not HTTP).

Moving Secrets Out of Client‑Side Code (Node.js Example)

Never store database credentials, API keys, or internal hostnames in JavaScript files served to the browser. Use environment variables and a backend proxy.

Bad practice (exposed `config.js`):

// config.js (publicly accessible)
const dbConfig = {
host: "prod-db.internal",
user: "admin",
password: "SuperSecret123",
database: "customer_data"
};

Secure approach:

Store secrets in a `.env` file on the server (never commit to version control):

DB_HOST=prod-db.internal
DB_USER=admin
DB_PASS=SuperSecret123
DB_NAME=customer_data

In your Node.js backend (e.g., server.js), load them with dotenv:

require('dotenv').config();
const dbConfig = {
host: process.env.DB_HOST,
user: process.env.DB_USER,
password: process.env.DB_PASS,
database: process.env.DB_NAME
};

Create an API endpoint that your frontend calls, never exposing raw credentials:

app.get('/api/config', (req, res) => {
// Return only non‑sensitive data (e.g., feature flags)
res.json({ apiBase: '/api/v1' });
});

Step‑by‑step migration guide:

Identify all hardcoded secrets in frontend JS files.
Move them to environment variables on the server.
Rewrite frontend requests to go through your backend API.
Remove the original `config.js` from the webroot.
Add `config.js` and `.env` to .gitignore.

4. Hardening CI/CD Pipelines to Prevent Accidental Exposure

Automate the detection of sensitive files before they reach production.

Pre‑commit Git Hook (Linux/macOS)

Create `.git/hooks/pre-commit`:

!/bin/sh
if git diff --cached --name-only | grep -E 'config.js|.env$'; then
echo "ERROR: Attempting to commit a sensitive file (config.js or .env)."
exit 1
fi

Make it executable: `chmod +x .git/hooks/pre-commit`

Using `gitleaks` for Secret Scanning

Install gitleaks: `brew install gitleaks` (macOS) or download from GitHub releases.
Run against your repo: `gitleaks detect –source . –verbose`

3. Integrate into CI (GitHub Actions example):

- name: Run gitleaks
uses: gitleaks/gitleaks-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Linting Rules (ESLint)

Add `eslint-plugin-no-secrets` to catch hardcoded credentials:

{
"plugins": ["no-secrets"],
"rules": {
"no-secrets/no-secrets": "error"
}
}

What this accomplishes: Prevents developers from inadvertently committing `config.js` or plaintext secrets, reducing the risk of exposure in public repositories or production builds.

5. Monitoring and Incident Response for Exposed Configs

If you discover that a `config.js` file has been publicly accessible, act immediately.

Immediate steps:

Revoke exposed credentials – Change database passwords, API keys, and any secrets found in the file.
Block direct access – Apply the server configuration rules from Section 2.

3. Check access logs for unusual patterns:

Linux: `sudo grep “config.js” /var/log/apache2/access.log`
– Windows (PowerShell): `Select-String -Path “C:\inetpub\logs\LogFiles\\.log” -Pattern “config.js”`

Scan for backdoor activity – Look for unexpected database queries or outbound data transfers.

Proactive monitoring with WAF rules:

Block requests to /config.js, `/.js` containing password, host, username.

Example ModSecurity rule:

SecRule REQUEST_URI "@rx /config.js$" "id:1001,deny,status:403,msg:'Sensitive Config Access'"

What Undercode Say:

Key Takeaway 1: Client‑side configuration files are a silent but critical risk – a single exposed `config.js` can hand over your database infrastructure to any attacker with a browser.
Key Takeaway 2: Prevention requires multiple layers: server‑side access controls, environment variables, CI/CD secret scanning, and real‑time monitoring.

Analysis: The discovery of an exposed `config.js` is not a low‑severity finding. In many real‑world breaches, information disclosure is the first step toward privilege escalation and data exfiltration. Developers often underestimate how easily directory brute‑forcing tools like `gobuster` or `ffuf` can uncover such files. Furthermore, the rise of client‑side heavy frameworks (React, Vue, Angular) increases the surface area for accidental exposure. A robust AppSec program must treat every JavaScript file as potentially sensitive until proven otherwise, enforce strict web server deny rules, and educate teams on why secrets never belong in the frontend.

Prediction:

As more organisations adopt micro‑frontends and serverless architectures, the misplacement of configuration files will become even more common, leading to automated scanning campaigns that specifically hunt for config.js, appsettings.json, and `.env` files. Attackers will increasingly use AI‑powered reconnaissance tools that not only discover exposed files but also instantly test extracted credentials against cloud databases and internal APIs. In response, the industry will shift toward dynamic secret rotation and zero‑trust client‑side principles, where even “non‑sensitive” configuration data is ephemeral and verified per session. Organisations that fail to implement server‑side access controls and environment‑based secrets management will face repeated, preventable breaches originating from a single exposed JavaScript file.

▶️ Related Video (78% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Nirju Dadhaniya – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post