highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Deploy config + secret rotationWhere it livesImplementationThis fix is applied in: Deploy config + secret rotation. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed config file: rotate the secrets, then move them off the web

Rotating leaked secrets and moving config out of the web root closes a plain-text path to your credentials.

The threat

The scanner requested a config file (something like /config.json or /appsettings.json) and got JSON back with connection-string or secret keys in it. Configuration files like these are meant to be read by your application at startup, from disk, not fetched over the internet by anyone who guesses the name.

The reason this rates as a secrets finding, not just an info leak, is what these files usually hold: a database connection string with the password in it, third-party API keys, SMTP credentials, a JWT signing key. All in plain text, one request away from the public. If the scanner can read it, so can anyone.

The exact fix

Two steps, in order. The secret is already out, so contain first, then stop serving.

1. Rotate every secret in the file, now. Treat each value as compromised: rotate the database password, reissue the API keys, roll the signing keys. Do this before anything else, because removing the file does not un-leak what has already been fetched.

2. Move secrets out of any web-served file. Real secrets belong in the environment or a secret manager, not in a file that sits in your publish directory:

  • Netlify / static builds: put secrets in the host’s environment variables and read them at build time. Never bake a secret into a JSON file the browser downloads.
  • .NET: keep appsettings.json out of wwwroot; supply secrets via environment variables, user-secrets in development, or a vault such as Azure Key Vault.
  • General: environment variables, AWS Secrets Manager, Doppler, HashiCorp Vault. Anything but a file under the web root.

Block the path as a backstop:

location ~* /(appsettings([.-][^/]*)?\.json|config\.json)$ {
    deny all;
    return 404;
}

A public config is fine, a secret one is not. Front-end apps legitimately ship non-secret settings (an API base URL, a public key). The rule is simple: if a value would hurt in a stranger’s hands, it does not belong in a file the browser can fetch.

Verify it

curl -s -o /dev/null -w '%{http_code}\n' https://yourdomain.com/appsettings.json

You want 404. If it returns 200 and the body contains keys like ConnectionStrings or ApiKey, the file is still exposed and those secrets need rotating.

Proof

The ApeCyber scanner catches this with a single GET from the outside, touching nothing. apecyber.com keeps its secrets in the host’s environment, never in a file the browser can fetch, and grades A / 100. Rotating the secrets and pulling the file is a clean −20 off the posture score.