Hey @shahabganji - thanks for the PR. Really welcomed that and that is an obvious gap.

In one of my customer projects we are using a very simplistic solution:

public static class HttpHeaderMiddlewareExtensions
{
    public static void UseHttpHeaderSecurity(this IApplicationBuilder app)
    {
        app.Use((context, func) =>
        {
            context.Response.Headers.Append("X-Frame-Options", "DENY");
            context.Response.Headers.Append("X-Permitted-Cross-Domain-Policies", "none");
            context.Response.Headers.Append("X-Xss-Protection", "1; mode=block");
            context.Response.Headers.Append("X-Content-Type-Options", "nosniff");
            context.Response.Headers.Append("Referrer-Policy", "no-referrer");
            context.Response.Headers.Append("Permissions-Policy",
                "camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), usb=()");
            context.Response.Headers.Append("Content-Security-Policy",
                "default-src 'self'");
            return func();
        });
    }
}

Is there any major advantage for the micro package over those few lines of code?

Hi @linkdotnet

In practice, not really! It adds some more headers and makes sure they are added properly!

This is what Andrew Lock pointed out in this post

The main problem with security headers is that there are a lot of them, and the list is generally growing and evolving, with new headers being introduced and others being retired. What's more, different headers use different patterns for lists—some use ; separators, others use ,, and others use a space—so it's easy to set them up incorrectly.
The NetEscapades.AspNetCore.SecurityHeaders package aims to help you set up security headers for your ASP.NET Core app. It provides sensible defaults, with a fluent builder pattern for customizing and configuring the headers for your specific application requirements.

I think, it'd be easier for someone who does not know how the security header's should be added or created to use this package! For me, whatever works in long run for the maintainance of this repo is fine!

Let’s get that in then!