Hey @luchua-bc. I reviewed your changes and took the liberty of adjusting some things.

• In cd9a485 I changed NullOrEmptyCheckSanitizer to be a BarrierGuard. Since you mentioned you couldn't make it work, I thought providing this example would help you. In any case, if this is only for a rare few edge cases, and considering that nullness checks are always a little problematic, I think the query would be simpler if we just removed this.
• In 81feaae I removed NullOrEmptyCheckGuard, for the reasons mentioned above, and also made a significant refactor to PatchMatchSanitizer. Since this is a big change, I want to explain why I did it. Feel free to disregard (revert) this commit if you don't agree with it:
  • You were checking for uses of the ! operator, assuming that the use of the negation meant that the developer wanted to exclude some words (blocklist), and if it wasn't used then it was checking for safe paths (allowlist). This isn't accurate — a developer could just use the negation with a safe path to implement a guard clause, or use an unsafe path (like WEB-INF) without the negation for the same reason.
  • Instead of that, what I thought could work better was just checking the strings being compared: if they're known "bad" strings like "WEB-INF" or "..", we consider that the check is a blocklist (and thus we set branch = false in the BarrierGuard). Otherwise, we consider it an allowlist and set branch = true. That way you don't need to worry about whether the check is being negated or not, or any other potential complexity around boolean checks. Of course this has caveats, but as an heuristic I think it improves the previous approach a little.
  • Also, I got rid of StringOperationSanitizer, since in my opinion it was too broad and wasn't modeling any security protection, just an access to the string contents. Even if the string is read, its contents need to be checked in some way to be considered safe, and I think the current guards already do that job.
  • Note that I changed the test case doHead5 from GOOD to BAD. If I'm not mistaken, that case would still be exploitable via double URL encoding, since that would bypass the "WEB-INF" check and would get decoded by getRequestDispatcher. That also fits with the simplified approach of requiring decoding protections for blocklist checks and path traversal protections for allowlist checks.
• Finally, in b6886b8 I just moved everything except the configuration to the QLL file, for convenience.

Thanks @atorralba a lot for the changes and the detailed explanation. I learned a new way to make the query more concise:-)

Thanks for your review @smowton.

@luchua-bc, I applied @smowton's comments regarding the rewrite I pushed. All the other suggestions are yours to handle :)

Thanks @atorralba for those new commits. I've made changes for all the other suggestions.

@smowton - please let me know if more changes are needed. Thanks.

Thanks a lot for all the help from @atorralba and @smowton.