Hi BILL Bella,
What you're describing is a common scenario where a Web Application Firewall flags a Base64-encoded payload because, once decoded or pattern-matched, it resembles a SQL injection signature. While it may be tempting to disable the rule entirely, I strongly recommend identifying the exact rule ID and request component (header, query parameter, JSON field, or request body section) that is triggering the detection before making any exceptions.
The safest approach is to review the WAF logs and examine the request details to determine precisely which parameter is causing the alert. Once identified, create a narrowly scoped exception that applies only to the specific API endpoint and parameter involved, rather than disabling SQL injection protection globally. If your WAF supports it, consider excluding inspection for that particular field while keeping all other SQL injection signatures active for the remainder of the request.
I would also recommend validating whether the Base64 content is expected to contain high-entropy or encoded application data and ensuring that it cannot be manipulated by external users to bypass protections. Testing the exception in a staging environment is important to confirm that legitimate requests are allowed while malicious payloads continue to be blocked. In many environments, using parameter-level exclusions combined with endpoint-specific matching provides the best balance between security and functionality.
As a best practice, document the reason for the exception, monitor the affected endpoint after deployment, and periodically review the WAF logs to ensure the exception remains appropriate. This helps avoid a situation where a temporary workaround becomes an unintended long-term security gap.
I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.
Jason