Notifications
Clear all
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.
NHIMG editorial — based on content published by Semgrep: security headers in ASP.NET and .NET Core
Questions worth separating out
Q: How should security teams keep web security headers from disappearing after deployment?
A: Put header policy in a deployment layer that survives republishing, then verify the live response after every release.
Q: Why do response headers fail in modern application delivery pipelines?
A: They fail when configuration is tied to a file or code path that the release process overwrites.
Q: What do teams get wrong about Content-Security-Policy and similar headers?
A: They often treat them as a one-time hardening task instead of a control that needs preservation and verification.
Practitioner guidance
- Move header policy into the durable delivery layer Define required security headers in the place least likely to be overwritten by app republishing, such as shared middleware, infrastructure templates, or edge configuration.
- Automate post-deploy header verification Add release checks that confirm Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and HSTS are present in the live response after every deployment.
- Restrict who can alter runtime hardening Treat response-header changes as security-sensitive configuration.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- The exact ASP.NET and .NET Core header code snippets used in the proof of concept
- The specific security header list the author added, removed, and plans to add later
- The practical comparison between web.config handling and startup.cs handling in different .NET setups
- The external guidance and testing sites the author used to validate the header configuration
👉 Read Semgrep's post on security headers in ASP.NET and .NET Core →
Security headers in .NET apps: are your controls surviving redeploys?
Explore further
02/08/2026 1:26 pm
Security headers are a deployment governance issue, not just a browser tuning task. The article shows that headers can be configured correctly and still disappear after a republish. That makes them a control-integrity problem across build, release, and runtime. For practitioners, the lesson is that application hardening must survive the delivery system, or it will not be dependable.
A question worth separating out:
Q: How do organisations know if security headers are actually working?
A: Check the live HTTP response from the deployed application, not just the source repository or build script. If the required headers appear consistently across environments and after release, the control is operating as intended. If they vanish after republishing, the policy is not durable enough to trust.
👉 Read our full editorial: Security headers in .NET apps: why they keep getting wiped out
