Topic starter
02/08/2026 12:27 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “Security headers for ASP.Net and .Net CORE”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Security headers can be configured correctly and still vanish after redeploy if the control path is not durable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:26 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Security headers in .NET apps: why they keep getting wiped out