HTTPS citizen applications need filtering against common Layer 7 web exploits such as injection and abusive bots. Which control is designed for that HTTP(S) application layer?
Select an answer to reveal the explanation.
Short Explanation
A WAF sits in front of the web app and looks at the HTTP conversation—not just IP and port—to swat injection attempts and nasty bots. Routes and backup policies do not read those payloads. For Layer 7 web abuse, the WAF is the right tool.
Full Explanation
A web application firewall filters HTTP(S) traffic at Layer 7 against common web exploits such as injection patterns and abusive bots. Citizen applications on HTTPS need that application-layer control because Layer 3 routing alone cannot inspect HTTP payloads. WAF placement protects municipal web apps without replacing secure coding.
Layer 3 static routes only choose next hops without inspecting HTTP. Cold-storage archival policies for backups do not filter web requests. Bare-metal BMC firmware updates are unrelated to HTTP request inspection.
Exam caveat: WAF ≠ NACL ≠ security group; WAF understands application requests. WAF rules need tuning to avoid blocking legitimate resident workflows.
Operational check: place a WAF in front of the citizen HTTPS apps, enable OWASP-style rule sets in detection then blocking mode, create exceptions carefully, and review blocked request logs. Include WAF metrics in the web platform’s monthly security report.
Correlate WAF blocks with application logs using request IDs so false positives affecting resident forms can be fixed quickly without disabling entire rule groups that still stop injection attempts. Retain rule-set versions in the change ticket for civic audits.