TL;DR: A .NET Core proof of concept showed how security headers can disappear on republish, leaving apps dependent on file-level configuration that does not persist cleanly across deployments, according to Semgrep. The governance problem is not adding headers once, but making protective response headers durable across build and release paths.
At a glance
What this is: This is a DevSecOps lesson about security headers in .NET apps, showing that headers can be lost when deployment patterns do not preserve the configuration path.
Why it matters: It matters because security controls that vanish during redeploys create a governance gap between intended protection and what users actually receive in production.
Context
Security headers are browser-facing controls that reduce exposure to XSS, clickjacking, content injection, and related web risks. In this article, the issue is not whether the headers are useful, but whether they survive the application lifecycle in a .NET Core deployment model that does not preserve the same configuration pattern as legacy web.config based apps.
That makes this a governance problem as much as a code problem. For IAM and security teams, the broader lesson is that control durability matters across build, publish, and runtime boundaries, especially where application security settings are embedded in code rather than managed as an external policy layer.
Key questions
Q: What breaks when security headers are not preserved across redeploys?
A: The protection does not disappear in theory, but it disappears in practice because the browser never receives the response headers that enforce policy. That leaves applications exposed to clickjacking, weaker content handling, and missing browser-side restrictions even though the codebase may still look hardened. The failure is control drift between intent and runtime.
Q: When should teams treat response headers as a deployment control issue?
A: They should do so whenever headers are defined in application code, middleware, or hosting layers that can change during publish, scaling, or migration. If the control can be removed by a new build, it belongs in release validation and operational ownership, not just in developer documentation. That is especially true for CSP and HSTS.
Q: What are the signs that security headers are failing in production?
A: The clearest sign is that live responses no longer include the expected CSP, HSTS, X-Frame-Options, Referrer-Policy, or X-Content-Type-Options values after a release. Another indicator is that the app behaves correctly in test but not after publish, which usually points to middleware order, hosting defaults, or configuration drift.
Q: How should teams govern browser protections in a DevSecOps pipeline?
A: Treat browser protections as testable release artefacts. Security teams should define the intended header set, verify it on deployed endpoints, and fail the release if the runtime output no longer matches policy. That approach turns headers from a one-time hardening task into a governed control with continuous assurance.
Technical breakdown
Why security headers can vanish in .NET Core deployment paths
Security headers such as Content-Security-Policy, X-Frame-Options, Referrer-Policy, and X-Content-Type-Options are delivered in HTTP responses, usually by middleware, reverse proxy, or server configuration. In older ASP.NET patterns, web.config often acted as the durable control point. In .NET Core, if headers are added in application code but the release path or startup configuration is altered, the protection can disappear even though the codebase appears correct. The failure is not that the header is hard to define, but that the control lives in a place where deployment behaviour can wipe it out or bypass it.
Practical implication: treat security headers as a release-boundary control and verify them after every publish, not just in source code.
How middleware placement affects header persistence
In .NET Core, header enforcement often sits inside startup middleware such as HSTS, X-Content-Type-Options, X-Frame-Options, and CSP configuration. Middleware order matters because later components can override, strip, or fail to emit the expected response headers. This is a common DevSecOps pattern issue: the control exists in code, but its runtime effect depends on execution order, hosting model, and whether the request path actually reaches that middleware. The security outcome therefore depends on operational correctness, not just developer intent.
Practical implication: validate middleware order and confirm headers on live responses from every application route.
Why header checks belong in pipeline and post-deploy verification
Response headers are easy to verify automatically, which makes them a strong candidate for deployment gate checks and post-release control validation. If a security header disappears after republishing, the environment has shifted from controlled protection to accidental exposure. For DevSecOps programmes, this is the same pattern seen when application security settings are present in development but not enforced in production. The control should be tested as part of the release process, not assumed from the code review alone.
Practical implication: add automated header verification to CI/CD so every deployment proves the control is still active.
NHI Mgmt Group analysis
Control durability is the real security question here. Security teams often focus on whether a header is configured, but the more important issue is whether that control survives republish, refactor, and hosting changes. In this case, the article shows that application security can regress simply because the control was anchored to a configuration path that did not persist. Practitioners should treat durability as part of control design, not an afterthought.
Header loss is a governance failure, not just a developer mistake. When response headers disappear across deployments, the organisation has no reliable assurance that runtime protections match policy intent. That is especially relevant in DevSecOps programmes, where build output and runtime behaviour can diverge unless verified continuously. Teams need release evidence that the control is present in production, not only committed in source.
Release validation is the missing control plane for browser protections. Browser security headers are effective only when they are consistently emitted by the deployed service. This article reinforces that application hardening must extend beyond code to the publish pipeline and the live edge of the service. For practitioners, the lesson is to govern headers as an operational control with measurable persistence.
Security headers are a lightweight but brittle part of web application defence. They reduce exposure to client-side abuse, but they are easy to lose when implementation depends on host-specific behaviour. That makes them a useful test case for broader application governance: if a simple control can vanish during redeploy, more complex security settings may be equally fragile. Teams should assume drift unless they can prove continuity.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Secrets Management Buyer's Guide
What this signals
Security headers are a good example of a control that appears simple but can be undermined by deployment drift. The practical challenge for readers is not whether to use CSP or HSTS, but whether their release process can prove those protections still exist after publish.
Header persistence gap: this is the gap between a control being written into code and that same control surviving the full delivery path into production. As DevSecOps matures, teams should expect more controls to fail this way unless runtime verification is built into the pipeline.
The behaviour gap is not abstract. Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec, which is a reminder that implementation discipline often breaks down at the point of release.
For practitioners
- Move header enforcement into a durable runtime control path Define security headers in the layer that survives publishing and hosting changes, then confirm the deployed application still emits them after each release.
- Add automated response-header checks to CI/CD Test for CSP, HSTS, X-Frame-Options, Referrer-Policy, and X-Content-Type-Options on live endpoints as part of deployment validation.
- Verify middleware order and hosting behaviour Review whether startup middleware, reverse proxies, or platform defaults are altering header emission before traffic reaches production users.
- Track header drift as a release regression Treat missing security headers after republish as a failed control, then compare the active runtime path against the intended configuration source.
Key takeaways
- Security headers can be configured correctly and still vanish after redeploy if the control path is not durable.
- The main risk is control drift between source code intent and the runtime headers that browsers actually receive.
- Continuous deployment validation should prove that browser protections still exist after publish, not just in development.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Security headers enforce browser-side secure communication behaviour on web responses. |
| V13 — Configuration | The control failure is tied to configuration durability across deployments. | |
| Recommendation — Apply V12 to verify that deployed applications consistently emit the expected response headers. Apply V13 to ensure security header configuration survives build and publish changes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about securing web application behaviour in release and runtime. |
| Recommendation — Use CIS-16 to embed header validation into application security testing and release checks. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | The issue is control drift in application configuration across releases. |
| Recommendation — Use PR.PS-01 to manage security header settings as part of controlled system configuration. | ||
Key terms
- Security Headers: HTTP response directives that tell a browser how to handle content, framing, transport, and referrer data. They reduce exposure to clickjacking, content injection, MIME sniffing, and some data leakage paths, but only if they are consistently delivered by the live application stack.
- Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
- Middleware: Middleware is the software layer that lets an application communicate with a token, reader, or cryptographic device. It translates device functions into calls the operating system or application can use. When middleware is missing or misconfigured, valid hardware can still appear unavailable or fail during authentication.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in practical terms. It helps security and IAM practitioners connect durable control design to broader identity security programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org