New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add an alternate version of EI_EXPOSE_REP #2898
Comments
That type of security concern tends to originate from the heyday of Java Applets. |
Yeah, but there's also that one where You can execute arbitrary toad if you throw an exception in the constructor... Either way my point is that mutable objects are actually also a bad coding practice (arguably), and generally would be better to replace with builder, record, and or effectively final objects (kind of what I'm talking here). It occurs to me I didn't think to mention builder since the builder itself is usually mutable so that would have to be recognized in some way although you could just suppress the class I suppose... |
https://content.api.news/v3/images/bin/8b236653aec2926939f9bf4c695efbda?width=1024 happens ;)
That's rather beyond the scope of what SpotBugs will ever enforce. |
Is it though? I mean it's something that spot bugs can do analysis on and already is. Really all I'm asking for is the ability to check but only check for public APIs. It's the same as this security vulnerability I just want to limit it to public APIs. |
So this particularly error seems kind of ludicrous to me
Essentially this is only a security vulnerability if someone has added malicious code to your jvm. In most cases if that happens you're beyond screwed. For my circumstances I'm going to ignore this.
That said, I generally agree that it's not a great idea to expose mutable variables. However, I think that these aren't a problem because they aren't publicly mutable. You could only change them reflectively (which I'm allowing for hibernate). Essentially they're effectively final.
I think the best solution/compromise would be a rule like
EI_EXPOSE_PUBLIC_REP
, that is not flagged as security. Public mutability is just not a great idea. I would not ignore this since it's something I'd want flagged as bad code.I think I would argue protected methods too, but definitely package protected ones, especially if you can detect a
module-info.class
which would prevent any weird shenanigans on that.Here's that class
The text was updated successfully, but these errors were encountered: