When a pull request changes configuration, check that defaults stay secure, no secrets are committed, errors do not leak detail, logs avoid sensitive data, transport and headers are not loosened, and environments stay separate. Configuration is code with fewer tests, so it deserves the same reading.
Why config changes slip through
A change to a settings file looks small and harmless: one line, a flag flipped. Reviewers skim it because it is not logic. Yet a single setting can turn on debug output, widen a network rule or disable certificate checks. The OWASP Secure Code Review Cheat Sheet includes a section on configuration and deployment for this reason.
The checklist
The OWASP checklist items for configuration and deployment give a solid base. Here they are turned into review questions.
| Area | Question for the diff |
|---|---|
| Secure defaults | Does this change make the default less strict? |
| Environment separation | Could a development value reach production, or the reverse? |
| Secrets | Is any key, token or password in the diff, even in a test file? |
| Error handling | Will errors now show stack traces or internals to users? |
| Logging | Is sensitive data now being logged, and are logs protected? |
| Security headers | Was a header removed or relaxed? |
| TLS | Were protocol versions or cipher choices weakened, or verification disabled? |
| Dependencies | Does the change pin, unpin or add a package or image? |
Secrets in config
OWASP's list says there should be no hardcoded secrets and that secrets need proper storage and rotation. In review, scan the diff by eye for long random-looking strings, anything named key, token or password, and connection strings with credentials in them. Ask where the real value comes from at runtime.
Reviewer comments on secrets should be urgent. If a real credential appears in a commit, assume it is exposed and ask for it to be revoked and replaced, not merely removed in a follow-up commit, because history keeps it.
Environment differences
Look for values that differ per environment. If a pull request sets debug: true, verify_ssl: false or a permissive CORS origin, ask which environment it applies to and how that is enforced. A setting that is safe in a local file may be dangerous if the same file is deployed.
OWASP lists proper isolation between environments. Check the diff does not point a test environment at production data, or reuse a production credential in a lower environment.
Defaults matter most
A new option often has a default. If the default is the permissive choice, the feature is permissive for everyone who does not read the docs. Ask for the secure default, with an explicit opt in to relax it.
Infrastructure and build files
Container files, deployment manifests and pipeline definitions are configuration too. Review them for broad permissions, mutable image tags and steps that run with more access than they need. They change what runs in production as surely as application code.
Make config reviewable
- Keep configuration in version control, so changes appear in diffs.
- Name security relevant files in code owners, so the right reviewer is notified.
- Add a test or startup check that fails if production runs with debug on.
- Prefer small configuration changes with a clear description of intent.
Quick check
Is a change to config alone low risk?
Not automatically. It can disable a control or widen access with one line. Review it for what it turns on or off.
What if a secret was committed by mistake?
Treat it as exposed. Revoke and replace it, then remove it from the code. Deleting the line alone does not remove it from history.
Sources
Last reviewed: 19 October 2026.
