A city WAF blocks several obvious SQLi probe strings during testing. What is the most appropriate next methodology choice?
Select an answer to reveal the explanation.
Short Explanation
A bouncer at the door does not mean the kitchen locks are solid. When a WAF swats obvious SQLi noise, keep going — IDOR, logic bugs, and misconfigs often live past the filter. Ending early or silently turning the WAF off is not how CPTS-style web testing works.
Full Explanation
A city WAF that blocks obvious SQLi probe strings is a useful control, not a certificate of overall application security. Methodology should continue into authorization, session, business-logic, and other web tests because many high-impact civic findings never look like signatured injection.
Ending the engagement because the WAF blocked probes wrongly equates perimeter filtering with assurance. Focusing only on inventing WAF bypass payloads while skipping authorization review misses IDOR and logic issues residents actually feel. Disabling the client's WAF without approval violates change control and RoE.
Exam caveat: WAFs may be bypassed or may fail open; absence of blocked probes does not prove injectability, and presence of blocks does not prove safety elsewhere.
Operational check: note which probes were blocked, then proceed with authenticated civic workflows, object-level authorization tests, and logic checks that do not depend on classic SQLi strings. Record WAF observations as environmental context, not as a reason to stop testing. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.