Credentials & Secrets
Private keys, credential files, and secret stores that scanners hunt for to harvest passwords and API keys.
26 probed paths in this category.
.aws/config
AWS CLI
Risk: The AWS CLI config file exposes profile names, default regions, role ARNs, and SSO/MFA settings, and if a paired credentials file is present, the access key ID and secret, granting direct programmatic access to the AWS account. Even without keys, the role and account structure aids targeted attacks.
Fix: Never place .aws/ files under a web-served directory, block dotfile access at the web server, and use short-lived IAM role credentials or instance profiles instead of long-lived keys stored on disk.
.aws/credentials
AWS credentials file
Risk: This file stores long-lived AWS access keys. Leaking it can give an attacker direct API access to your cloud account - data exfiltration, resource hijacking for crypto-mining, and lateral movement across services.
Fix: Never store AWS keys in the web root. Prefer short-lived IAM roles and instance profiles over static keys, scope permissions tightly, and rotate and revoke exposed keys immediately.
.bash_history
Bash shell command-history file that can leak commands and credentials
Risk: Shell history can reveal full commands including passwords passed as arguments, API tokens, database connection strings, and internal hostnames, giving an attacker both credentials and operational intelligence.
Fix: Keep user home directories out of webroots, avoid passing secrets as command-line arguments, restrict history file permissions, and ensure the server returns a 404 without leaking file contents for such probes.
.htpasswd
Apache Password File
Risk: Exposes usernames and hashed passwords for HTTP Basic Auth, which an attacker can crack offline to gain access to the protected area.
Fix: Place the password file outside the document root, ensure the server blocks .ht* requests, and use strong bcrypt hashes; rotate credentials if the file was reachable.
.mysql_history
MySQL client command-history file that can leak queries and credentials
Risk: Exposes the plaintext history of MySQL client commands, often including credentials passed via IDENTIFIED BY clauses, schema details, and sensitive WHERE-clause values that aid further data exfiltration.
Fix: Set MYSQL_HISTFILE=/dev/null or symlink ~/.mysql_history to /dev/null on shared/service accounts, and ensure the web root never overlaps a user home directory; block dotfiles at the web server.
.netrc
Plaintext credential file used by ftp, curl, and other tools for automatic login
Risk: This plaintext file stores login and password pairs for FTP, HTTP, and API endpoints used by curl and other tools, so exposure directly hands an attacker reusable credentials for those services.
Fix: Never store .netrc in web-accessible locations, set permissions to 600, prefer credential helpers or environment-based secrets over plaintext, and rotate any credentials that may have been exposed.
.npmrc
npm configuration file that can contain registry auth tokens
Risk: Leaks the _authToken for npm registries, letting an attacker publish malicious package versions under your scope or pull private packages.
Fix: Keep .npmrc outside the served directory, inject tokens via CI environment variables rather than committed files, and rotate any token that may have been exposed.
.pypirc
Python package-index configuration file that can contain PyPI credentials
Risk: Reveals PyPI/index usernames and passwords or API tokens, enabling an attacker to upload trojaned releases of your packages or access a private index.
Fix: Store upload credentials in environment variables or a secrets manager instead of .pypirc, restrict file permissions to 0600, and deny dotfile access at the web server.
.ssh/authorized_keys
SSH Authorized Keys
Risk: Reveals which public keys grant SSH access and their comments (often user@host), letting an attacker enumerate valid accounts and target the corresponding private keys or append their own key if write access is found.
Fix: Keep the .ssh directory outside the web root with mode 700, deny dotfile serving at the server level, and audit authorized_keys for unexpected entries.
.ssh/id_dsa
OpenSSH DSA private key file (legacy)
Risk: This legacy DSA private key allows SSH impersonation of its owner where the public key is authorized; DSA's weak 1024-bit keys are also more susceptible to cryptographic attack, compounding the risk.
Fix: Remove DSA keys from any web-accessible path, migrate off DSA to Ed25519 or RSA, revoke the exposed key from all authorized_keys files, and enforce strict key file permissions.
.ssh/id_ed25519
OpenSSH Ed25519 private key file
Risk: An exposed Ed25519 private key, if unencrypted or weakly passphrased, lets an attacker authenticate as the key owner to any server trusting the matching public key, granting direct shell access and lateral movement.
Fix: Never place SSH keys in web-served directories, always passphrase-protect private keys, restrict file permissions to 600, and immediately revoke and rotate any key suspected of exposure.
.ssh/id_rsa
SSH Private Key
Risk: A readable OpenSSH private key lets an attacker authenticate as the key's owner to any host trusting it, granting direct shell access and lateral movement across the infrastructure.
Fix: Never place private keys under a web-served directory; restrict keys to mode 600, passphrase-protect them, and rotate any key that may have been exposed.
.ssh/known_hosts
OpenSSH known_hosts file listing previously connected servers
Risk: This file maps out the servers the host regularly connects to, giving an attacker a reconnaissance list of internal hostnames and IPs to target for lateral movement, even though hashed entries limit direct readability.
Fix: Keep .ssh out of web-served directories, enable HashKnownHosts to obscure host entries, and ensure scanners probing this path receive a clean 404 rather than file contents.
ansible-vault.yml
Ansible Vault Encrypted File
Risk: Even though Vault files are encrypted, exposure lets attackers attempt offline brute-force of the vault password and reveals which hosts and secrets exist; a weak vault password yields full credential access.
Fix: Keep vault files out of web-accessible paths, use a strong unique vault password stored separately, and prefer a runtime secret manager over checked-in vault files.
aws.yml
AWS credentials file
Risk: Exposes AWS access key ID and secret access key, granting the attacker direct API access to the account to read S3 buckets, spin up compute for cryptomining, or pivot across the AWS environment.
Fix: Never commit credential files to web roots or repos; serve a clean 404, rotate any leaked keys immediately, and use IAM roles or a secrets manager instead of static keys on disk.
certificate.pem
SSL Certificate
Risk: While the public certificate itself is not secret, its exposure in the web root fingerprints the server, reveals issuer/SAN details and expiry, and signals that the matching private key may sit nearby.
Fix: Serve certificates only through the TLS stack, not as downloadable files, and ensure the private key is stored separately outside the document root.
config/aws.yml
AWS credentials file
Risk: Leaks AWS credentials from an application's config directory, giving an attacker programmatic control over the account's S3, EC2, and IAM resources for data theft or resource abuse.
Fix: Keep config directories outside the document root, block access to credential files via server rules, rotate exposed keys, and move secrets to IAM roles or a secrets manager.
config/secrets.yml
Rails Secrets Configuration
Risk: Exposure leaks the Rails secret_key_base and other tokens, letting an attacker forge and tamper with signed session cookies, which can escalate to authentication bypass or deserialization-based RCE.
Fix: Migrate to Rails encrypted credentials, keep secrets in environment variables, and confirm the config/ directory is never inside the public document root.
credentials.json
Generic credentials file commonly used by Google and other SDKs
Risk: Often contains OAuth client secrets or service-account keys for Google and other SDKs, allowing an attacker to impersonate the application and call backend APIs.
Fix: Move credential files outside the document root, load secrets from environment variables or a secrets manager, and add the filename to .gitignore and web-server deny rules.
gcp-credentials.json
Google Cloud Platform credentials file probed for cloud key theft
Risk: Exposes Google Cloud Platform credentials that an attacker can use to authenticate to GCP APIs and pivot into your project's storage, databases, and compute.
Fix: Keep credential files out of the web root, prefer keyless Workload Identity Federation, and rotate plus audit the affected service account immediately on exposure.
id_rsa
SSH Private Key
Risk: An exposed private key enables an attacker to impersonate its owner over SSH and gain interactive access to any server configured to trust the corresponding public key.
Fix: Store keys only in restricted-permission home directories outside the document root, protect with a passphrase, and immediately revoke and rotate any leaked key.
private.key
Private Key File
Risk: Recovering the private key lets an attacker decrypt intercepted TLS traffic, impersonate the service with a valid certificate, or forge signatures depending on the key's purpose.
Fix: Keep private keys outside the web root with strict file permissions, and rotate plus reissue the associated certificate immediately if exposure is suspected.
s3cmd.ini
s3cmd configuration file containing AWS access and secret keys
Risk: Discloses AWS access_key and secret_key, granting an attacker direct API access to read, modify, or delete S3 buckets and any other resources the IAM credentials permit.
Fix: Never place s3cmd.ini under the web root, use IAM instance roles instead of long-lived keys, and immediately rotate and audit any exposed key pair.
secrets.yaml
Kubernetes Secrets Configuration
Risk: A Kubernetes Secret manifest exposes base64-encoded (not encrypted) credentials such as TLS keys, database passwords, and service-account tokens that attackers can decode instantly.
Fix: Keep secret manifests out of web roots and repos, use a sealed-secrets or external secrets manager, and rotate any exposed credentials immediately.
server.key
SSL Private Key
Risk: Possession of the TLS server private key allows an attacker to impersonate the HTTPS site and, without forward secrecy, decrypt previously captured encrypted sessions.
Fix: Store the key in a path the web server cannot serve (or in an HSM/keystore), restrict to mode 600, and reissue the certificate with a fresh key if leaked.
service-account.json
Google Cloud service-account key file granting API access
Risk: Provides a Google Cloud service-account private key, letting an attacker authenticate as that identity and access any GCP resource its IAM bindings allow (storage, compute, BigQuery, etc.).
Fix: Store the key outside the served tree or use Workload Identity to avoid key files entirely, restrict the account to least privilege, and revoke the key if exposed.