FAQ

We ask for a temporary WAF exclusion to avoid blocked or altered test traffic. This ensures accurate results and helps identify security findings in the application itself.

We use a temporary rule allowing traffic only from our static IP used for testing. The customer then removes the rule after the retest phase is complete.

A WAF is only a mitigation layer. Unpatched security findings remain exploitable if the WAF is misconfigured or bypassed. Secure code ensures long-term protection.

Even if a WAF enforces rate limits, the application should have its own controls. Relying only on the WAF creates a single point of failure – if it’s bypassed or misconfigured, attackers can abuse the system.

They help ensure the scope of work is fully covered and that no endpoints or functions are missed during testing. If they’re not available, we still perform a thorough assessment through manual and automated discovery.

We work in the following approaches:
Blackbox – we act as an external attacker with no credentials, focusing on authentication, external exposure, public endpoints, and the attack surface.
Graybox – we assume the attacker has obtained some access/credentials, focusing on authorization, privilege escalation, and internal logic issues.

We test in staging or production. Staging is preferred if it’s identical to production, as it reduces the risk of system impact. Otherwise, testing can be done in production with proper coordination. We don’t test in lower environments due to frequent changes.

Changes can hide or create security findings, disrupt evidence, and affect accuracy. A stable environment ensures reliable results.