Security headers in .NET apps: why they keep getting wiped out

At a glance

What this is: This is a blog post about adding and preserving web security headers in an ASP.NET and .NET Core proof of concept, with the key finding that redeployments can silently remove them.

Why it matters: It matters because response headers are a low-friction control that affects browser-side risk, and identity and application teams need configuration that survives CI/CD, not just a one-time hardening pass.

👉 Read Semgrep's post on security headers in ASP.NET and .NET Core

Context

Security headers are browser-side controls that tell the client how to handle content, framing, transport, and metadata exposure. In this post, the core issue is not whether headers are useful, but whether they remain in place after deployment changes. That is a configuration governance problem, and it sits close to application security, DevSecOps, and the identity and access decisions that determine who can alter runtime behaviour.

The author shows a familiar gap: protections are added in one layer, then lost when the app is republished or the framework layout changes. For teams running modern delivery pipelines, that is a reminder that hardening has to be treated as code and verified continuously. The pattern is common in application security programmes, not an edge case.

Key questions

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. If the only copy lives in application code or a framework-specific file, a later build can remove it. Durable controls belong in shared middleware, templates, or edge policy, backed by automated checks.

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. In practice, this is a drift problem: the secure state defined by the team is not the secure state that runs in production. That makes the control fragile unless it is enforced outside the app artifact.

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. Headers reduce browser-side risk, but only if they remain present after the next deployment, platform change, or migration. The control is effective when it is repeatable, not when it is merely documented.

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.

Technical breakdown

How security headers shape browser trust

Security headers are HTTP response directives that influence how a browser renders, isolates, or rejects content. Content-Security-Policy limits where scripts, styles, and frames may load from. X-Frame-Options reduces clickjacking exposure. X-Content-Type-Options prevents MIME sniffing. Referrer-Policy limits how much navigation context is leaked. These controls do not fix server-side flaws, but they reduce the impact of injection, framing, and data leakage when application code misbehaves. Their value depends on consistent delivery from the application stack, reverse proxy, or web server layer.

Practical implication: set header policy at a layer that survives app redeploys, not only inside transient application code.

Why redeployments often strip response hardening

The article highlights a deployment pattern problem. In some stacks, especially when configuration is split between web.config, startup code, and platform defaults, a publish cycle can overwrite the location where headers were added. That means the control exists only as long as the specific implementation artifact survives. This is a classic drift issue: the intended state and the deployed state diverge after the next build, package, or framework change.

Practical implication: treat header settings as deployment-managed policy and verify them in post-release checks.

Why browser hardening belongs in DevSecOps pipelines

Browser hardening is often seen as a front-end concern, but it is actually part of the application delivery chain. If security headers are introduced manually, they are easy to lose. If they are enforced through pipeline templates, infrastructure configuration, or platform middleware, they become repeatable and auditable. That matters because application security controls that cannot be reproduced across environments rarely remain effective at scale. The real security question is not whether the app had headers once, but whether the pipeline guarantees them every time.

Practical implication: build automated checks that fail deployment when required headers are missing.

NHI Mgmt Group analysis

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.

Configuration drift is the real failure mode here. The risky condition is not the absence of security knowledge, but the gap between intended and deployed state. When controls live in the wrong layer, they are overwritten, bypassed, or forgotten during framework changes. Teams should treat that as a control assurance problem, not a one-off coding mistake.

Content-Security-Policy and framing controls remain foundational for web application risk reduction. Even basic response headers materially reduce exploitability when applications handle untrusted content or embed third-party assets. They do not replace secure coding or identity-aware access control, but they narrow the browser-side attack surface. Practitioners should verify them as part of standard application security baselines.

Identity and access governance still matters because only the right release paths should change security headers. A header policy that can be edited casually by application developers or lost in an automated release needs stronger change control. That means separating administrative authority, reviewing pipeline permissions, and proving that the final runtime configuration matches policy. The operational conclusion is simple: protect the controls that protect the application.

Browser hardening and secrets discipline intersect in the same delivery pipeline. When teams already struggle to preserve secret handling, certificate settings, and secure defaults across environments, response headers often suffer the same fate. The named concept here is hardening drift: protective settings that exist in source or one environment but fail to persist through the next release. Practitioners should measure controls by persistence, not by implementation intent.

What this signals

Hardening drift: controls that are correct in source or one environment but disappear after release should be monitored as a repeatable failure pattern. For application teams, that means every security header should have a post-deploy assertion, not just a code review note. Where identity, access, and release permissions overlap, the person or system that can change deployment policy effectively controls the control plane.

For programme owners, the next step is to connect browser hardening with broader configuration assurance. That includes pipeline permissions, release validation, and runtime configuration baselines. If those elements are not joined up, security headers become decorative rather than enforceable.

For practitioners

• 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. Avoid relying on a single framework file if deployment tooling can replace it.
• 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. Limit pipeline and production access so only approved release paths can modify the effective header set.
• Align browser controls with secure coding and dependency review Use headers to reduce exposure, but pair them with input validation, output encoding, and dependency review so that browser protection is not the only thing standing between users and abuse.

Key takeaways

• Security headers only reduce risk when they persist across deployment and republishing events.
• The real weakness is configuration drift, where the intended browser protections do not match the live application state.
• Teams should automate verification and place header policy in a durable release layer rather than in fragile app-local 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.
• Content Security Policy Bypass: A failure where an allowlist or browser content policy permits data to leave through a destination that should no longer be trusted. In AI agent attacks, this matters because outbound channels can be used to exfiltrate information after the model has already been steered into unsafe behavior.

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

👉 Semgrep's full post shows the header code, framework differences, and validation steps.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore the course if your programme needs stronger control over identities, secrets, and access governance.