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:
Directive | Purpose |
---|---|
default-src | Fallback policy — usually 'self' only |
script-src | Allows inline/eval scripts for dev tools (restricted in production) |
style-src | Permits unsafe-inline for simple styling without complex hashing |
img-src | Allows loading from self, data URIs, and trusted CDNs |
media-src | Supports audio from SoundCloud, video from YouTube, etc. |
frame-src | Required for embedded content like YouTube/Vimeo |
connect-src | Needed for AJAX/fetch/WebSocket use in apps |
form-action | Ensures form submissions only go to your domain |
base-uri / worker-src | Blocks 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