|
194 | 194 | </rule> |
195 | 195 |
|
196 | 196 | <rule ref="category/java/security.xml"/> |
| 197 | + |
| 198 | + <rule name="AvoidSystemSetterCall" |
| 199 | + language="java" |
| 200 | + message="Setters of java.lang.System should not be called unless really needed" |
| 201 | + class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"> |
| 202 | + <description> |
| 203 | + Calling setters of java.lang.System usually indicates bad design and likely causes unexpected behavior. |
| 204 | + For example, it may break when multiple Threads are setting the value. |
| 205 | + It may also overwrite user defined options or properties. |
| 206 | + |
| 207 | + Try to pass the value only to the place where it's really needed and use it there accordingly. |
| 208 | + </description> |
| 209 | + <priority>3</priority> |
| 210 | + <properties> |
| 211 | + <property name="xpath"> |
| 212 | + <value> |
| 213 | + <![CDATA[ |
| 214 | +//MethodCall[starts-with(@MethodName,'set')]/TypeExpression[pmd-java:typeIsExactly('java.lang.System')] |
| 215 | +]]> |
| 216 | + </value> |
| 217 | + </property> |
| 218 | + </properties> |
| 219 | + </rule> |
| 220 | + |
| 221 | + <rule name="AvoidPostConstruct" |
| 222 | + language="java" |
| 223 | + message="Avoid @PostConstruct" |
| 224 | + class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"> |
| 225 | + <description> |
| 226 | + Using a `@PostConstruct` method is usually only done when field injection is used and initialization needs to be performed after that. |
| 227 | + |
| 228 | + It's better to do this directly in the constructor with constructor injection, so that all logic will be encapsulated there. |
| 229 | + This also makes using the bean in environments where JavaEE is not present - for example in tests - a lot easier, as forgetting to call the `@PostConstruct` method is no longer possible. |
| 230 | + </description> |
| 231 | + <priority>3</priority> |
| 232 | + <properties> |
| 233 | + <property name="xpath"> |
| 234 | + <value> |
| 235 | + <![CDATA[ |
| 236 | +//MethodDeclaration[pmd-java:hasAnnotation('jakarta.annotation.PostConstruct')] |
| 237 | +]]> |
| 238 | + </value> |
| 239 | + </property> |
| 240 | + </properties> |
| 241 | + </rule> |
| 242 | + |
| 243 | + <rule name="AvoidPreDestroy" |
| 244 | + language="java" |
| 245 | + message="Avoid @PreDestroy" |
| 246 | + class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"> |
| 247 | + <description> |
| 248 | + `@PreDestroy` should be replaced by implementing `AutoCloseable` and overwriting the `close` method instead. |
| 249 | + |
| 250 | + This also makes using the bean in environments where JavaEE is not present - for example in tests - a lot easier, as forgetting to call the `@PreDestroy` method is no much more difficult. |
| 251 | + </description> |
| 252 | + <priority>3</priority> |
| 253 | + <properties> |
| 254 | + <property name="xpath"> |
| 255 | + <value> |
| 256 | + <![CDATA[ |
| 257 | +//MethodDeclaration[pmd-java:hasAnnotation('jakarta.annotation.PreDestroy')] |
| 258 | +]]> |
| 259 | + </value> |
| 260 | + </property> |
| 261 | + </properties> |
| 262 | + </rule> |
| 263 | + |
| 264 | + <rule name="AvoidUnmanagedThreads" |
| 265 | + language="java" |
| 266 | + message="Avoid unmanaged threads" |
| 267 | + class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"> |
| 268 | + <description> |
| 269 | + Trying to manually manage threads usually gets quickly out of control and may result in various problems like uncontrollable spawning of threads. |
| 270 | + Threads can also not be cancelled properly. |
| 271 | + |
| 272 | + Use managed Thread services like `ExecutorService` and `CompletableFuture` instead. |
| 273 | + </description> |
| 274 | + <priority>3</priority> |
| 275 | + <properties> |
| 276 | + <property name="xpath"> |
| 277 | + <value> |
| 278 | + <![CDATA[ |
| 279 | +//MethodCall[pmd-java:matchesSig('java.lang.Thread#start()') or pmd-java:matchesSig('java.lang.Thread#startVirtualThread(java.lang.Runnable)') or pmd-java:matchesSig('java.lang.Thread$Builder#start(java.lang.Runnable)')] |
| 280 | +]]> |
| 281 | + </value> |
| 282 | + </property> |
| 283 | + </properties> |
| 284 | + </rule> |
| 285 | + |
| 286 | + <rule name="JavaObjectSerializationIsUnsafe" |
| 287 | + language="java" |
| 288 | + message="Using Java Object (De-)Serialization is unsafe and has led to too many security vulnerabilities" |
| 289 | + class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"> |
| 290 | + <description> |
| 291 | + Nearly every known usage of (Java) Object Deserialization has resulted in [a security vulnerability](https://cloud.google.com/blog/topics/threat-intelligence/hunting-deserialization-exploits?hl=en). |
| 292 | + Vulnerabilities are so common that there are [dedicated projects for exploit payload generation](https://github.com/frohoff/ysoserial). |
| 293 | + |
| 294 | + Java Object Serialization may also fail to deserialize when the underlying classes are changed. |
| 295 | + |
| 296 | + Use proven data interchange formats like JSON instead. |
| 297 | + </description> |
| 298 | + <priority>2</priority> |
| 299 | + <properties> |
| 300 | + <property name="xpath"> |
| 301 | + <value> |
| 302 | + <![CDATA[ |
| 303 | +//ClassDeclaration[@Interface = false()]/ClassBody/FieldDeclaration/VariableDeclarator/VariableId[@Name='serialVersionUID'] | |
| 304 | +//ConstructorCall/ClassType[pmd-java:typeIsExactly('java.io.ObjectInputStream') or pmd-java:typeIsExactly('java.io.ObjectOutputStream')] |
| 305 | +]]> |
| 306 | + </value> |
| 307 | + </property> |
| 308 | + </properties> |
| 309 | + </rule> |
197 | 310 | </ruleset> |
0 commit comments