SONARKT-569 Modify rule S4830: add support for WebViews

[antonioaversa]

SONARKT-569

Review

A dedicated reviewer checked the rule description successfully for:

• logical errors and incorrect information
• information gaps and missing content
• text style and tone
• PR summary and labels follow the guidelines

[egon-okerman-sonarsource]

Needs a few structural changes to be fully "LaYC up-to-date", which we apparently forgot to do for S4830 in Java/Kotlin.

[antonioaversa]

Needs a few structural changes to be fully "LaYC up-to-date", which we apparently forgot to do for S4830 in Java/Kotlin.

As suggested, I have adapted the "How to fix section" to have both compliant and non-compliant code examples, to have a coherent experience with other languages such as docker.

In order to match that, I have moved the ==== Implementing a server certificate validation up, and make it become === Compliant solution, so that the two code snippets are now next to each other, and the code diff between the two makes sense. I have kept the === How does this work? the same as it is in docker and other languages.

Let me know if that looks better for you.

Regarding LaYC: the migration of this rule for Kotlin was done in #2176
In general, I don't think that only having non-compliant makes this section non-fully LaYC compliant, as the "How to fix it" section can have any free structure, if that fits better the story-telling:

This tab could also use a freeform 'story-telling' style if that makes it clearer for the user. Feel free to use any of the titles below, or any other titles you find useful. (ref)

The optionality also applies to "How does this work", and any other level 3 section.

Given the above, I think that the way Java was done looks good to me: the non-compliant code example doesn't have a corresponding compliant, since all the proposed solutions for Java are ways to not use a custom trust manager at all, so I don't think we should bend the structure to meet a LaYC layout which is defined as optional, and proposed as an example of how things should look.

If anything I would remove the ==== Noncompliant code example and === How does this work? titles: the first kind of implies that there is a compliant solution, and the second in my opinion should be the incipit of the entire How to fix section. But I think this is more for a later change, across all languages.

[egon-okerman-sonarsource]

Regarding LaYC: the migration of this rule for Kotlin was done in #2176
In general, I don't think that only having non-compliant makes this section non-fully LaYC compliant, as the "How to fix it" section can have any free structure, if that fits better the story-telling:

You're right, my previous comment was wrong. As the recommended fix is omitting a trust manager, it makes sense for there only to be one code sample instead of two in the JCE case. For Android, this is different, so I think your fix makes sense here as well.

[egon-okerman-sonarsource]

LGTM, I suggested two changes for consistency with other security rules.

[sonarqube-next]

Quality Gate passed for 'rspec-tools'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[sonarqube-next]

Quality Gate passed for 'rspec-frontend'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube