StefanOssendorf / SecurityHeadersMiddleware

OWIN Middlewares to set useful security-related HTTP header (STS, Anti-Clickjacking, XSS, CSP).
MIT License
27 stars 9 forks source link

Header handling per header #6

Open StefanOssendorf opened 9 years ago

StefanOssendorf commented 9 years ago

Implement header handling per header.

E.g.

/// <summary>
/// Specifies the handling of the header.
/// </summary>
public enum HeaderHandling {
    /// <summary>
    /// If the header is already set, it will be replaced with the configured value.
    /// </summary>
    OverwriteIfHeaderAlreadySet = 0,
    /// <summary>
    /// If the header is already set, it will not be overwritten and the configured value will be ignored.
    /// </summary>
    IgnoreIfHeaderAlreadySet,
    /// <summary>
    /// If the header is already set, the value will be appended. 
    /// </summary>
    AppendToHeaderIfHeaderAlreadySet,
    /// <summary>
    /// If the header is already set, an additional header will be added with the configured value. <br/>
    /// This value is only valid with: <see cref="ContentSecurityPolicyConfiguration">CSP</see>.
    /// </summary>
    AddAdditionalHeaderValueIfHeaderAlreadySet
}

@damianh Can you help me with a design decision, please?

Not all header supports all options. e.g. ContentTypeOptions only support "Overwrite" and "Ignore". ContentSecurityPolicy supports all four.

Should I split the enum into multiple? Or an public nested enum in every middleware?

Thanks in advance

damianh commented 9 years ago

I'll take the principal of least surprise + discoverability over DRY any day. That is, I suggest public nested enum in each MW instead of trying to share this with all of them.

This is nice MW btw, will be using it :)

StefanOssendorf commented 9 years ago

For each MW an enum is probably the best solution. Thanks!

Great :-) Feedback is appreciated.