What are common mistakes with appsettings.json?

Common mistakes with appsettings.json are putting connection strings, API keys, and identity secrets into a file that ships with the application, then leaving it readable in deployments or source control. Attackers commonly search for this file to steal credentials and tokens. Separate secrets from configuration, use environment-specific overrides carefully, and scan builds and repositories for leaked values.

Why appsettings.json becomes a secret-leak problem

The file itself is not the issue. The mistake is treating appsettings.json as a safe place for anything that can authenticate, authorize, or unlock access. Once connection strings, API keys, or identity secrets land there, they are easy to copy into source control, image layers, backups, and deployment artifacts.

That creates a broader exposure than many teams expect. A value meant for one environment often ends up readable in another, and a single leaked file can expose production data paths, third-party services, or token-based access. The problem is usually less about the configuration format and more about uncontrolled secret distribution.

Teams commonly make this worse by assuming “internal” files are low-risk. In practice, build systems, support bundles, developer machines, and configuration previews are all places where appsettings content can surface. For identity-bearing material, the leak matters because the credential or token is the access path, not just a setting.

How these mistakes usually happen in real deployments

One common failure is committing secrets into the repository and then copying the same file into every environment. Another is using a shared appsettings file for both configuration and sensitive values, which makes change control easier but security separation much harder. A third is depending on environment-specific overrides without proving they actually override every sensitive field.

The risk increases when teams generate configuration during CI/CD and do not inspect what is written to logs, artifacts, or container layers. Secret values can also persist in test fixtures, sample files, local developer copies, and old deployment packages. If a secret is ever written in plaintext, it should be assumed recoverable unless there is a clear deletion and rotation process.

A useful way to think about the issue is how authentication material fails when it is handled like ordinary configuration. The same mistake pattern appears across app secrets, service credentials, and tokens: the value is operationally convenient, so it gets copied too widely and protected too lightly.

What good secret handling looks like instead

Separate non-sensitive configuration from secret material. Keep appsettings.json for settings that can safely be visible, and move credentials, tokens, certificates, and similar values into a secret store or platform-native secret mechanism. If you must use environment-specific files, make the secure path the default, not the exception.

Use layered configuration carefully, because overrides only help if they are actually enforced in every environment. Developers should not need production secrets in their local appsettings file, and production should not depend on a file that is easily copied out of a repository. Scanning repositories, build outputs, and deployed images for exposed values should be part of release hygiene, not a one-time cleanup.

For teams managing many service credentials, OWASP Non-Human Identity Top 10 is a useful lens because appsettings mistakes often expose machine credentials rather than human passwords. The control question is simple: if the file is copied outside its intended boundary, does it reveal something that can still be used to obtain access?

Risk and Threat Considerations

Leaked configuration files are attractive because they often contain stable credentials, bearer tokens, or connection details that bypass normal user-facing controls. Attackers search for these files in repos, backups, public artifacts, and compromised hosts because one exposed value can unlock several downstream systems.

Failure mechanism: Sensitive values are stored in a file that is widely distributed by build, deployment, or source control processes, then reused long after the file leaves its intended trust boundary.

Impact: An attacker can steal credentials or tokens, access services as the application, move into adjacent systems, and trigger data exposure or unauthorized actions without needing to break the application itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Appsettings.json secret storage creates exposed credentials and tokens.
	NHI-07 — Long-Lived Secrets	Leaked config often leaves reusable secrets valid for too long.
Recommendation — Move secrets out of appsettings and store them in a managed secret system. Shorten secret lifetime and rotate values after any exposure or copy event.
CIS Controls v8	CIS-3 — Data Protection	Protects sensitive data at rest, including secrets embedded in configuration files.
Recommendation — Classify and protect configuration artifacts that contain sensitive values.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle management for passwords, tokens, and similar authenticators.
	CM-6 — Configuration Settings	Appsettings misuse is a configuration-control failure.
Recommendation — Centralize authenticator lifecycle and rotate exposed secrets promptly. Enforce secure configuration baselines that separate settings from secrets.

Practitioner Guidance

What to verify: Confirm that appsettings.json contains no live secrets in any environment that can be checked in, packaged, logged, mirrored, or shared with developers. If a value can authenticate to a system, treat it as secret material rather than configuration.

Decision rule: If a secret must be present at runtime, store it outside the application file and rotate it whenever it has been committed, copied, or bundled. If you cannot prove where it has propagated, assume exposure and treat rotation as the safer default.

Common mistake: Teams often fix the repository copy but forget artifact caches, container images, test fixtures, and old release bundles. That leaves the same secret available through a second path even after the source file is cleaned up.

Practitioner takeaway: The real control objective is not “hide the file,” but prevent secrets from becoming part of the application’s distributable state in the first place.