Configuration correctness should be validated automatically on every deployment — not manually checked occasionally:
• HTTP header scanning: Mozilla Observatory (observatory.mozilla.org) and SecurityHeaders.com analyze response headers and grade them. Integrate these checks via their APIs into CI/CD — fail the deployment if the grade drops below a threshold.
• TLS scanning: Qualys SSL Labs or testssl.sh (open source, runnable in CI) validate TLS version, cipher suites, and certificate configuration. Run on every deployment to catch TLS regressions.
• DAST (Dynamic Application Security Testing): OWASP ZAP in automation mode can scan for CORS misconfigurations, verbose errors, exposed admin paths, and missing headers. Run as part of a staging environment deployment check.
• Configuration audit scripts: Write lightweight scripts that call each API endpoint and assert: correct CORS headers, no stack traces in error responses, 405 for unexpected methods, all security headers present. These run in minutes and catch regressions immediately.
Manual configuration review catches issues at a point in time. Automation catches regressions. A developer changes a middleware configuration to debug an issue, forgets to revert it, and the change deploys. An automated check in the deployment pipeline catches this before it reaches production. Without automation, misconfiguration is a matter of when, not if.
Store security configuration (CORS origins, TLS settings, header policies) in version-controlled configuration files rather than runtime settings. Changes require pull requests, reviews, and audit trails — the same process as code changes. This brings configuration under the same rigor as application logic.
Ask your team whether security configuration is checked automatically on every deployment — or manually, occasionally, by someone who remembers to do it. Manual checks are how misconfigurations persist for months unnoticed.