Content Security Policy (CSP) in ASP.NET Core

Content Security Policy (CSP) in ASP.NET Core

Content Security Policy CS(P) in ASP.NET Core: A Practical Middleware Pattern

🔹 Protect your users. Guard your brand. And do it without breaking your frontend.

A well-implemented Content Security Policy (CSP) is one of the most effective defenses against cross-site scripting (XSS), clickjacking, and other code injection attacks. Yet too often, developers either over-tighten policies (breaking legit features) or skip it entirely.

In my DevStack, I’ve already solved this.

Let’s explore how I dynamically generate a production-ready CSP header with minimal fuss in an ASP.NET Core 8 app.

What This Middleware Does

This block of middleware inspects your environment (Development or Production) and appends:

  • ✅ A flexible Content-Security-Policy header
  • ✅ Extra security headers (X-Frame-Options, Referrer-Policy, etc.)
  • ✅ Local development allowances for WebSocket debugging or Hot Reload
  • ✅ Third-party script/CDN/iframe exceptions (YouTube, SoundCloud, Cloudflare…)

You don’t need to juggle dozens of meta tags or rewrite headers per route—just plug it into your pipeline.

🧱 Key Directives

Here's a breakdown of what's covered:

DirectivePurpose
default-srcFallback policy — usually 'self' only
script-srcAllows inline/eval scripts for dev tools (restricted in production)
style-srcPermits unsafe-inline for simple styling without complex hashing
img-srcAllows loading from self, data URIs, and trusted CDNs
media-srcSupports audio from SoundCloud, video from YouTube, etc.
frame-srcRequired for embedded content like YouTube/Vimeo
connect-srcNeeded for AJAX/fetch/WebSocket use in apps
form-actionEnsures form submissions only go to your domain
base-uri / worker-srcBlocks unwanted redirects or rogue blob workers in prod

And yes, it’s production-tuned by default. The moment you flip the environment, security scales up without you touching a thing.

Want Even More Secure?

Here’s what else I ship with this policy in production:

context.Response.Headers.Append("X-Content-Type-Options", "nosniff");
context.Response.Headers.Append("X-Frame-Options", "SAMEORIGIN");
context.Response.Headers.Append("Referrer-Policy", "strict-origin");

That’s a robust trio of protections most sites still miss—despite how easy it is to add.

Want This In Your App?

🔹 You could build it from scratch.

🔹 Or you could request access to DevStack—where this is already done.

Better yet, if you’re running a real-world business and not just a dev sandbox, my business-first approach might interest you.

I’ve spent over 30 years building web systems that monetize effectively, support SEO from day one, and keep maintenance costs low.

"Ask me how I came up with one feature that added $25,000 in yearly sales for a client."

I’m not just coding for elegance—I’m coding for outcomes.

Want CSP Reporting or Violation Logs?

CSP can optionally log policy violations via report-uri or report-to. Want to capture when someone tries to inject script via browser plugins or outdated widgets? That’s an easy add-on I can wire up.

Final Thought

Most developers still treat CSP as an afterthought. But in a security-first world, it should be part of your architecture, not a browser band-aid.

Let’s get it right from the start. Talk to me about securing your ASP.NET Core stack or embedding this logic in your existing middleware.

Would you like a follow-up post on:

  • 🔐 CSP violation logging with report-to
  • 🔍 How to test your headers with Lighthouse or SecurityHeaders.com
  • 💡 Tighter CSPs using nonce or hash-based script-src?

Let me know, and I’ll queue it up.

Also see:

Ready to elevate your security posture and ship faster?

Let’s make something that wins you the next meeting.

Not a presentation—a conversation starter.

→ Book a discovery call or Request access to DevStack

security