When conducting a penetration test, being asked to whitelist a tester’s IP address from certain security controls might sound counterintuitive.

After all, aren’t those controls there to protect the application? They are. But depending on the objective of the penetration test, leaving them in place can actually prevent testers from properly assessing the security of the application itself.

The role of WAFs and rate limiting

Web Application Firewalls (WAFs) and rate limiting are two common security controls used to protect web applications.

A WAF can identify and block potentially malicious requests before they ever reach the application, while rate limiting restricts the number of requests that can be made within a certain period. Both are valuable layers of defence in a production environment. However, during a penetration test, they can also create a barrier between the tester and the application they are actually there to assess.

Are you testing the WAF or the application?

A penetration test is typically conducted within a defined timeframe, with the goal of identifying vulnerabilities and misconfigurations within the application.

This principle is reflected in the Australian Signals Directorate’s Information Security Manual (ISM), which describes vulnerability assessments and penetration tests as security assessment activities designed to identify and triage vulnerabilities within systems and help organisations better understand their exposure to cyber threats. If a WAF blocks testing payloads before they reach the application’s underlying logic, however, the tester may spend valuable testing time interacting with the WAF rather than assessing the application itself. Rate limiting can create a similar problem by significantly slowing testing activity.

The result?

A vulnerability may exist within the application but remain undiscovered because the security control sitting in front of it prevented the tester from reaching the vulnerable functionality. This can create an incomplete picture of the application’s actual security posture.

Defence in depth still matters

Whitelisting a penetration tester does not mean WAFs, rate limiting or other security controls are ineffective or unnecessary.

Quite the opposite.

These controls are important components of a defence-in-depth security strategy. However, they should not be relied upon as the only protection against vulnerabilities within an application.

The OWASP Web Security Testing Guide (WSTG) notes that network-level components such as firewalls and intrusion prevention systems can have a significant impact on testing. It also explains that while WAFs can be effective against certain attack types, such as SQL injection and cross-site scripting, they can be less effective against vulnerabilities involving areas such as access control and business logic.

This distinction is important during penetration testing. The objective is not simply to determine whether a malicious request can pass through the WAF, but to understand how the application itself behaves when presented with unexpected or malicious input.

WAF bypass techniques and weaknesses also evolve over time. If an underlying application vulnerability has been masked by the WAF rather than remediated, a future bypass could expose that vulnerability to an attacker. The stronger approach is to ensure the application is secure at its core, while maintaining additional security controls as further layers of protection.

The Takeaway

Where the objective of a penetration test is to assess the security of the application itself, relevant security controls should generally be whitelisted for the tester’s authorised IP address. This gives the penetration tester direct access to assess the application’s functionality and underlying logic without unnecessary interference from controls such as WAFs or rate limiting.

The goal is not to make the penetration test easier.

It is to make sure we are testing the right thing.