Config & Environment Files
Application and environment configuration files that often leak connection strings and secrets.
27 probed paths in this category.
.env
A file where you can store your sensitive data like API keys, passwords, etc.
Risk: App environment files routinely hold database passwords, API keys, and secret tokens in plaintext. Reading one often hands an attacker full database access, cloud credentials, and the ability to impersonate the application.
Fix: Never web-serve dotfiles: block requests for .env and other hidden files at the web server or CDN, keep secrets out of the web root, and load them from environment variables or a secrets manager. Rotate anything that may have leaked.
.env.bak
A file where you can store your sensitive data like API keys, passwords, etc.
Risk: A served backup of a .env file leaks application secrets - database credentials, API keys, encryption/session keys - allowing full database access, third-party account abuse, and forging of signed tokens.
Fix: Store environment files outside the web root, deny dotfile and .bak access in server config, keep secrets in env vars or a secrets manager, and rotate any credentials that may have leaked.
.env.development
Development Environment Configuration
Risk: Development dotenv files frequently contain database URLs, API keys, and debug credentials that, while labeled dev, often share secrets or network paths with production systems.
Fix: Never deploy .env files to web-accessible paths, block dotfiles at the server/CDN, and rotate any secret that was ever committed or served.
.env.local
Local Environment Configuration
Risk: This dotenv file typically holds API keys, database URLs, and app secrets in plain text; if served, an attacker can extract credentials to pivot into databases, third-party services, and cloud accounts.
Fix: Keep .env files outside the webroot and add a server rule denying any request for files beginning with a dot, especially .env*.
.env.production
Production Environment Configuration
Risk: Production environment files expose live secrets - production database passwords, payment and cloud provider keys, signing secrets - allowing an attacker to compromise the production system and connected services directly.
Fix: Never deploy .env files into the served directory; inject production secrets via the platform's environment variables or a secrets manager and block dotfile requests at the server.
.env.staging
A file where you can store your sensitive data like API keys, passwords, etc.
Risk: Exposes staging environment secrets such as database credentials and API keys; even if staging-only, reused or similar credentials and connection details give attackers a foothold and information about production architecture.
Fix: Keep env files outside the web root, deny dotfile access at the server, use distinct non-production credentials for staging, and rotate any exposed keys.
.env.test
Test Environment Configuration
Risk: Test environment files leak service credentials, fixture API keys, and test-account logins that attackers can replay against staging or shared backends.
Fix: Exclude all .env variants from deploy artifacts and version control, and ensure the web server returns 404 for any dotfile request.
.htaccess
Apache Configuration
Risk: Discloses rewrite rules, access restrictions, authentication directives, and protected directory locations, helping an attacker bypass controls or locate hidden resources.
Fix: Configure the server to deny serving files beginning with .ht (Apache does this by default; verify the directive is intact) and prefer main config over per-directory .htaccess.
admin/config.json
Admin Configuration File
Risk: An admin configuration file commonly exposes API keys, admin credentials, or internal endpoints, giving an attacker the information needed to access privileged administrative functions.
Fix: Serve configuration from outside the webroot, require authentication on all admin paths, and avoid storing secrets in client-fetchable JSON.
admin/config.php
phpMyAdmin
Risk: If readable, a phpMyAdmin/CMS config file discloses database hostnames, usernames, and passwords plus secret/blowfish keys, letting an attacker connect directly to the database and forge authenticated sessions.
Fix: Ensure config files are parsed by PHP rather than served as text, keep them outside the webroot or restrict access, and rotate any credentials that may have been exposed.
app/config/parameters.yml
Symfony
Risk: This Symfony parameters file holds database credentials, mailer settings, and the app secret used for CSRF and session signing, enabling data theft and session forgery if exposed.
Fix: Keep config files outside the web-served public directory, deny access to YAML files at the web server, and move secrets to environment variables or a secrets manager.
application.properties
Spring Boot Configuration
Risk: A Spring Boot properties file typically holds datasource URLs and passwords, management endpoint settings, and integration secrets, giving an attacker direct database and service credentials.
Fix: Externalize secrets to environment variables or a vault, package application.properties inside the jar rather than a static path, and ensure the server does not serve resource files directly.
cms/config.php
phpMyAdmin
Risk: A CMS or phpMyAdmin config.php discloses database credentials, secret keys, and connection details, letting an attacker access the database directly and potentially forge authenticated sessions or admin tokens. This commonly leads to full content-management and data compromise.
Fix: Place config.php outside the web root or deny HTTP access to it, set file permissions to 640, and load database secrets from environment variables instead of a served PHP file.
conf/config.ini
phpMyAdmin
Risk: A configuration ini for phpMyAdmin or similar tooling can expose database hostnames, usernames, passwords, and auth secrets, granting an attacker direct database access and the ability to forge sessions. Plaintext credentials here typically compromise the backing data store.
Fix: Store config.ini outside the document root with restrictive permissions, block direct HTTP access to .ini files at the web server, and reference secrets from environment variables rather than committing them to served files.
config.json
JSON configuration file
Risk: A web-exposed config file commonly leaks database connection strings, API keys, or session secrets that let an attacker access backend services or forge authenticated sessions.
Fix: Store configuration outside the web root, deny direct access to .json config files at the server level, and serve a clean 404 without stack traces or version banners.
config/CONFIG
Docker
Risk: Exposed Docker or registry config files can leak registry credentials, image references, and environment settings, letting an attacker pull or push images and pivot into the container infrastructure.
Fix: Keep Docker config and registry credential files out of web-served directories, store secrets in a vault or Docker secrets, and ensure the web server returns a clean 404 for such paths.
config/config.php
phpMyAdmin
Risk: This phpMyAdmin configuration file contains the database host, username, password, blowfish secret, and control-user settings, giving an attacker direct database credentials and the ability to forge auth cookies. With the DB credentials they can read or modify all application data.
Fix: Keep config.php outside the web root or block .php config files from direct HTTP access, set restrictive file permissions (640), and never store plaintext DB credentials where the web server serves them.
config/settings.inc.php
phpMyAdmin
Risk: This phpMyAdmin or PrestaShop configuration file contains database hostnames, usernames, and passwords, granting an attacker direct database access if disclosed.
Fix: Store configuration outside the web root or deny direct access via web server rules, set restrictive file permissions, and never serve .php source as plaintext.
includes/config.php
PHP include configuration file commonly containing credentials
Risk: Discloses application secrets such as database credentials, API keys, and framework salts, allowing an attacker to authenticate to the database or forge session tokens and escalate to broader application compromise.
Fix: Store the config outside the document root or load secrets from environment variables, and add web server rules to deny direct access to files in the includes directory.
inventory.ini
Ansible Inventory File
Risk: An Ansible inventory exposes hostnames, IP addresses, SSH users, and group structure for managed infrastructure, giving an attacker a precise target list and sometimes connection parameters.
Fix: Do not serve inventory files over HTTP, keep them in restricted repos, and avoid embedding credentials or ports as inventory variables.
js/config.js
GitLab
Risk: An exposed GitLab or front-end config file can leak API endpoints, application settings, and occasionally tokens or keys embedded client-side, aiding reconnaissance and account compromise.
Fix: Keep secrets out of client-side JavaScript, serve only non-sensitive runtime config, and inject any required tokens server-side with proper scoping.
local/local.yml
Ansible
Risk: An exposed Ansible playbook can reveal inventory hosts, task logic, file paths, and any inline variables or vault references, disclosing infrastructure layout and sometimes hardcoded secrets used for provisioning. This gives an attacker a blueprint of the deployment and privileged hosts.
Fix: Keep Ansible playbooks and inventories out of any web-served directory, store secrets in Ansible Vault rather than inline, and restrict repository access so deployment automation is never publicly reachable.
settings.json
Application Settings File
Risk: Application settings files frequently include database connection strings, third-party API keys, and tokens; exposure lets an attacker reuse those credentials against the app and its integrations.
Fix: Place settings files outside the served directory or load configuration from environment variables, and block direct requests for .json config files.
terraform.tfstate
Terraform State File
Risk: Terraform state stores resource attributes and often plaintext secrets (DB passwords, access keys, private IPs), giving an attacker a full inventory and credentials for the cloud infrastructure.
Fix: Store state in an encrypted, access-controlled backend such as S3 with bucket policies and never serve it from a web directory; rotate any secrets found in state.
terraform.tfvars
Terraform Variables File
Risk: Variable files commonly hold provider credentials, API tokens, and account IDs in plaintext, enabling an attacker to authenticate directly to the cloud accounts being provisioned.
Fix: Exclude tfvars from version control and deploy bundles, source secret variables from a vault or environment at apply time, and rotate any leaked values.
web.config
IIS Web Configuration
Risk: This IIS configuration file can reveal connection strings, machine keys, custom handlers, and rewrite rules; a leaked machineKey enables ViewState forgery that can lead to remote code execution.
Fix: IIS blocks web.config by default - verify that protection is intact, store secrets in protected config sections or environment variables, and never copy web.config into a downloadable location.
web.xml
Java Web Application Deployment Descriptor
Risk: The Java deployment descriptor exposes servlet mappings, security constraints, and sometimes credentials or internal endpoints, helping an attacker enumerate hidden functionality and bypass access controls.
Fix: Ensure the WEB-INF directory remains protected by the servlet container (it is non-served by spec) and remove any credentials from the descriptor, storing them in JNDI or environment variables.