K
Half-serious response: throw the whole thing away, WAFs are somewhere between "more trouble than they're worth" and "worse than useless". They're like antivirus except their detection (both sensitivity and accuracy) is somehow even worse, they break your site when they misbehave, and there's no way for a legit user to bypass them. The protection they provide is marginal; a competent attacker or even well-written script can almost always bypass them.
(Reasons this is only half-serious: there are a few things that a WAF can meaningfully detect with confidence, the alerting can be useful even if the blocking is overzealous, and WAFs provide a central management point for other useful traits like blocking suspicious source IPs or 0-day known exploits... though how well they do at that is highly variable. There is perhaps no single thing that a WAF is the best answer for, but they are a convenient place to put a lot of occasionally-valuable checks.)
Fully-serious response: you should be able to disable that rule or at least downgrade it to "notify" from "block" (possibly even only for that endpoint) and there's no good reason not to. Preventing SQL injection is a solved problem - just use parameterized queries and avoid any form of string concatenation in SQL - and it's impossible to prevent with a regex anyhow. You could also possibly enable a mode between "notify" and "block" where e.g. allow the first nine flagged requests in a minute are logged but allowed, and the tenth or later one gets blocked... but of course that risks filling up logs with false positives and blocking legit users during high-traffic periods.
Base64 encoding is an interesting idea; some (few) WAFs will recognize this and decode it, but most will ignore it. The reason not to do that, though, is less about the WAF and more about the actual security you should have behind it; any time you're adding encoding and decoding to your flow, you risk performing a validation or escaping step (e.g. for XSS) on the encoded data, which of course finds nothing. (It is also true that, assuming the WAF doesn't itself recognize and decode base64, you'll be in effect completely turning off its content rules for that endpoint, even the ones that are theoretically adding value.)
You asked why WAFs are so popular then, and it's a fair question. In my experience, the answer is some combo of:
Lying vendors promising they can solve all your security problems[*] to ignorant and credulous executives[**]
People coming to expect it (encouraged by the same vendors, of course) and thus making it a contractual requirement to have one
A "checkbox" approach to security where the question is "do you have XSS protection" and not "has anybody competent ever checked if they can get XSS on your site"
Lots of people who can't be bothered to read even the basics of web security and thus deploy sites with gaping holes and, when this bites them, take the least-effort approach to "fixing" the problem
The fact that there are in fact a lot of script kiddies out there trying dead-easy-to-block attacks, so a WAF sure looks like it's providing value by blocking them all (and is in fact providing some value, if you're in the group mentioned in the previous point)
Actual value even to people who have put in any meaningful security effort, in the form of e.g. malicious IP filtering and similar checks that it's reasonable to delegate to external software. Even though in most cases you could do better with a fine-grained and context-aware filter implemented in your server, it'd just be more effort to create and maintain
[*] Usually described as "Prevent the entire OWASP Top 10" or similar. This is neither accurate (there are several items in the current top 10 list that a WAF will never be able to handle even in theory), nor sufficient (lots of critical security vulnerabilities are not in the current top 10, though some have been in the past).
[**] As far as I can tell, there is simply no accountability in this field, and the vendors know this so they just don't care. My employer recently was faced with the requirement to procure a WAF in order to close a big contract. Every vendor promised us a miracle solution. Every time, I was able to find multiple pages of bypasses in under a day's work. They never cared. We eventually picked one - a really big, well-trusted company's product, you've heard of them - largely on the basis of "easy to deploy, it'll stay out of our way, and doesn't cost too much". Our bug bounty testers didn't even break their stride, using bypasses I hadn't even noticed in those quick tests.
