A new WFO1000 security analyzer affects excessive members of custom controls, even when these members aren't used for serialization

[DmitryGaravsky]

Hello team!

My name is Dmitrii, and I am writing on behalf of the DevExpress WinForms Team.

First, thank you for your tremendous effort in advancing the .NET platform and, especially, in improving the security and maintainability of .NET applications.

As stated in the documentation, the WFO1000 security analyzer aims to enhance the security and maintainability of Windows Forms apps by enforcing proper serialization practices, thereby reducing the risk of accidental data exposure.

However, in some cases, it flags certain members that cannot be used for serialization, which can be considered false positives.

The affected cases include:

1. Private properties of components that do not have the InitializeComponent method:

public class CustomControl1 : Control {
    // This property's value can't be used for serialization but is flagged by WFO1000
    public string? Value1 {  get; private set; }
    // This property's value can't be used for serialization but is flagged by WFO1000
    public string? Value2 {  get; internal set; }
}

2. Both private and public static properties of components:

public class CustomControl2 : Control {
    // This property's value can't be used for serialization but is flagged by WFO1000
    public static string? Value1 { get; set; }
    // This property's value can't be used for serialization but is flagged by WFO1000
    public static string? Value2 { get; private set; }
}

3. Both private and public overridden properties of standard controls descendants that are already configured for serialization at the base-component level:

public class CustomControl3 : Control {
    // This property has a ShouldSerializeCursor method at the Control type level,
    // and this ShouldSerializeCursor method is actually used during serialization
    public override Cursor Cursor {
        get => base.Cursor;
        set => base.Cursor = value;
    }
}

4. Both public and protected properties of interfaces derived from IComponent:

public interface ICustomInterface : IComponent {
    // This property's value can't be used for serialization but is flagged by WFO1000
    // And it is impossible to add DefaultValue attributes or ShouldSerialize/Reset methods here
    Rectangle Bounds { get; set; }

    // This property's value can't be used for serialization but is flagged by WFO1000
    // And it is impossible to add DefaultValue attributes or ShouldSerialize/Reset methods here
    Size Size { get; protected set; }
}

To reproduce these issues, you can create a new .NET 9 WinForms application and insert the code samples above.

Previous Behavior

Previously, for the cases mentioned above, properties of custom Windows Forms controls could be used without explicit serialization configuration (because no configuration was needed in those cases). The analyzers did not produce warnings.

Current Behavior

The analyzers now produce warnings such as:

WFO1000: Property 'property' does not configure serialization for its property content.

Impact

The impact of this change can be substantial. For example, in our case as a control vendor, thousands of flagged points appear in our codebase, many of which are false positives - we have numerous internal components and control's parts that are can not be publicly used, and we are 100% certain they are not involved in design-time serialization processes. But we fully understand the underlying reasons for this analyzer and appreciate their importance, so we are addressed all of these flagged points at our side.

Our primary goal with this bug report is to advocate for a refinement of this analyzer's behavior to mitigate any negative effects and to help developers transition to more secure serialization practices without compromising their productivity or project stability. However, the excessive false positives generated by the WFO1000 analyzer can affect thousands of developers worldwide, particularly those managing large, complex Windows Forms projects. For teams with the WarningsAsErrors option enabled, the inability to compile due to false-positive warnings significantly disrupts development workflows and productivity.

Please feel free to reach out if additional information or specific examples from our codebase would be helpful in refining the analyzer’s behavior. We’re eager to collaborate and provide feedback to ensure this analyzer supports a smoother transition for developers worldwide.

Kind regards,
Dmitrii
DevExpress WinForms Team

[KlausLoeffelmann]

On it.
Please note, that you can disable this Analyzer by adding the respective entry to the .editorconfig, which then needs be put to the root of the solution. Put the severity to None or Silent, and then the behavior is as before.

[DmitryGaravsky]

On it!

Great!

Thank you for your response and the suggestion regarding .editorconfig. We fully understand that we can adjust the analyzer's severity on our side. However, the issue extends beyond our internal development, as it also affects our customers who build applications using our control library sources.

While reviewing the analyzer further, I identified another case that cannot be avoided on our side:

4. Both public and protected properties of interfaces derived from IComponent:

public interface ICustomInterface : IComponent {
    // This property's value can't be used for serialization but is flagged by WFO1000
    // And it is impossible to add DefaultValue attributes or ShouldSerialize/Reset methods here
    Rectangle Bounds { get; set; }

    // This property's value can't be used for serialization but is flagged by WFO1000
    // And it is impossible to add DefaultValue attributes or ShouldSerialize/Reset methods here
    Size Size { get; protected set; }
}

I have updated my original post to include this fourth case. Could you please take a look and consider this scenario as well?

Thank you again for your attention to this matter!