Switch order of literals to prevent NullPointerException

[citizenjosh]

This change defensively switches the order of literals in comparison expressions to ensure that no null pointer exceptions are unexpectedly thrown. Runtime exceptions especially can cause exceptional and unexpected code paths to be taken, and this can result in unexpected behavior.

Both simple vulnerabilities (like information disclosure) and complex vulnerabilities (like business logic flaws) can take advantage of these unexpected code paths.

Our changes look something like this:

  String fieldName = header.getFieldName();
  String fieldValue = header.getFieldValue();
- if(fieldName.equals("requestId")) {
+ if("requestId".equals(fieldName)) {
    logRequest(fieldValue);
  }

More reading

• http://cwe.mitre.org/data/definitions/476.html
• https://en.wikibooks.org/wiki/Java_Programming/Preventing_NullPointerException
• https://rules.sonarsource.com/java/RSPEC-1132/

Powered by: pixeebot (codemod ID: pixee:java/switch-literal-first)

[CLAassistant]

All committers have signed the CLA.

[ibodrov]

This bot need more training.

[drdavella]

@ibodrov thanks for the feedback on this PR!

I'm a maintainer of @pixeebot and just wanted to point out that @pixeebot is not actually using AI to make this change. We use an OSS framework called Codemodder: https://github.com/pixee/codemodder-java

This particular codemod is implemented here: https://github.com/pixee/codemodder-java/blob/main/core-codemods/src/main/java/io/codemodder/codemods/SwitchLiteralFirstComparisonsCodemod.java

A big part of our philosophy is to introduce proactively defensive changes that have no downside. In this particular case, it seems you've identified four places where the code potentially benefits from this hardening and five places where maybe it's not as obviously useful.

Given that, I'm curious whether you see any downside to merging the code as-is given that it's a defensive change that also reflects a best practice? Your feedback is appreciated.