Fine-Tuning AWS WAF Without Compromising Security

Overview

Web application firewalls (WAFs) play an important role in protecting applications from malicious traffic, but effective protection is not simply a case of enabling security rules and leaving them untouched.

As applications evolve, so does the way users interact with them. New workflows, increased activity and unexpected usage patterns can all change what normal traffic looks like.

In this first part of our series on operating AWS WAF in real-world environments, we explore what happens when legitimate customer activity triggers a rate-limiting rule, and how to investigate and tune the configuration without weakening security.

In one customer environment, legitimate requests began exceeding the configured rate limit, highlighting an important operational reality: security controls need to evolve alongside applications and the way they are actually used.

The final part of the series looks at Cross-Site Scripting and How AWS WAF Helps Protect Applications, including how legitimate requests can sometimes trigger XSS protection rules.

Challenge

The initial WAF configuration was designed around the expected traffic profile and security best practices available when the rules were introduced. The application itself was operating normally, but further observation revealed that some legitimate customer workflows could generate a higher volume of requests within a short period than had originally been anticipated.

This was not a case of the WAF being incorrectly configured. Rather, it uncovered a new and previously unexpected way in which users were interacting with the service.

We needed to understand:

• Which requests were being blocked
• Which WAF rule was responsible
• Whether the traffic was malicious or legitimate
• Why legitimate workflows were generating higher request volumes
• How the protection could be adjusted without weakening the application's security

The investigation showed that an IP-based rate limiting rule was blocking legitimate traffic. The rule had been configured to allow 300 requests within five minutes, providing a reasonable baseline based on the information available at the time. However, real-world customer usage had revealed workflows that could legitimately exceed this threshold.

Solution

Rather than simply removing the rate limit, we investigated the traffic using AWS WAF logs.

The logs allowed us to identify the blocked requests, the rule responsible and the application endpoints receiving the traffic. This provided the evidence needed to distinguish legitimate customer activity from potentially malicious traffic and understand the usage pattern that had triggered the rule.

We then adjusted the rate limit to better reflect the observed application behaviour while retaining protection against abnormal request volumes.

Our platforms are designed with environment-specific configuration as standard practice. This meant that the appropriate differences between production and non-production environments could be configured easily without changing the underlying approach or introducing a new configuration model.

We also encountered a Terraform provider issue when modifying the WAF configuration. A workaround was implemented so the WAF remained fully managed through infrastructure as code.

The result was not simply a higher rate limit. It was a more informed security configuration based on evidence from real application behaviour.

Results

The changes:

• Restored legitimate requests that had been blocked
• Reduced disruption for higher-volume user workflows
• Allowed WAF thresholds to reflect actual application usage
• Maintained protection against abnormal request volumes
• Kept the configuration managed through Terraform
• Allowed the appropriate environment-specific configuration to be applied easily

Most importantly, the investigation demonstrated a repeatable approach for handling this type of situation: monitor the behaviour, investigate unexpected traffic, understand how the service is actually being used, and then make targeted security changes based on evidence.

This is an important part of operating security controls in a live environment. The expected user profile is not always fully known when a service is first deployed, and legitimate usage patterns can change over time due to new workflows, changing customer behaviour or increased adoption.

Conclusion

Security controls should protect applications without becoming an obstacle to legitimate users. As applications and customer behaviour evolve, WAF rules may need to be reviewed and tuned based on real-world usage.

In the final part of our series, Cross-Site Scripting and How AWS WAF Helps Protect Applications, we look at how legitimate requests can sometimes trigger XSS protection rules.

At Mesoform, we design secure, observable cloud platforms where security controls evolve alongside the applications they protect. If your WAF is blocking legitimate traffic or your rules no longer reflect real-world usage, we can help investigate and tune them without compromising protection.