rspec/rules/S3011/comments-and-links.adoc

=== on 23 Jul 2015, 07:15:31 Nicolas Peru wrote:
Not sure if it should be part of the description but it is not really clear if the rule is limited to the API in the example.

=== on 23 Jul 2015, 09:05:19 Ann Campbell wrote:
FYI [~tamas.vajk]

=== on 19 Apr 2018, 10:53:30 Alexandre Gigleux wrote:
This is a "Security Weakness".

=== on 4 Sep 2018, 10:28:09 Alexandre Gigleux wrote:
\[~nicolas.harraudeau] Review 

I think you should ask yourself if this rule is only relevant for Java. If this is the case, it is no longer a Common Security Hotspot rule.

Check if C#, VB.Net are really excluded, I don't think so. Also I believe PHP, Swift, Scala, Kotlin, Ruby should be in the list of Targeted Languages. 



=== on 4 Sep 2018, 11:29:31 Nicolas Harraudeau wrote:
\[~alexandre.gigleux] Thanks for the review

Here are examples for the targeted languages: \https://rosettacode.org/wiki/Break_OO_privacy

Ruby is a special case.

=== on 6 Apr 2020, 12:01:04 Eric Therond wrote:
Altering accessibility at run-time is not possible if a security manager is configured (in Java) or the code doesn't have the right permission (https://docs.microsoft.com/fr-fr/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection[in C#]).


So a new security-hotspot rule could be relevant in the future to detect when a loose permission is granted that allow, for instance, external code to change accessibility of fields of a trusted code and thus access to private information, however here:

* The rule raises when the accessibility is changed, so basically "the consequence" and not the root cause of the bug is highlighted.
* Reflection will be most of the times used to create dynamic types or to perform debugging.

So a code smell is more appropriate than a security rule.