712-50 Question 325
Single answerIdentify web application vulnerabilities and attacks and web application security tools to counter attacksA financial services company is preparing to launch a new customer web portal that processes loan applications and stores uploaded identity documents. During final testing, the security team discovers that a user can modify a numeric parameter in a URL and retrieve another applicant's document metadata. The development team says a web application firewall (WAF) in front of the portal will be enough to address the issue before go-live. As the CISO, which action is the MOST appropriate to reduce the actual risk while supporting a secure release?
- A
Delay go-live until the application enforces server-side authorization checks on every object request, and use the WAF only as a compensating detective/preventive control
- B
Proceed with go-live because the WAF can reliably block parameter tampering and prevent unauthorized object access without code changes
- C
Encrypt the document metadata fields in the database and proceed, because encrypted records cannot be abused through URL manipulation
- D
Replace the numeric identifiers in the URL with Base64-encoded values and proceed, because encoded references are not predictable
Show answer and explanation
Correct answer: A
Explanation
This scenario tests executive-level understanding of web application vulnerabilities and the proper role of security tools. The issue is broken access control, commonly described in OWASP guidance as IDOR or, more broadly, Broken Access Control/Broken Object Level Authorization. OWASP consistently identifies broken access control as a top web application risk because it can expose sensitive data even when other controls are present. Best practice is to enforce server-side authorization checks on every request for every protected object, using deny-by-default logic and validating that the requested resource belongs to or is permitted for the authenticated user. A WAF can be deployed as a compensating or layered control, especially for short-term risk reduction, but it should not be treated as the primary remediation for flawed business logic or missing authorization. Relevant references include the OWASP Top 10 guidance on Broken Access Control, the OWASP Authorization Cheat Sheet, and NIST secure software development guidance emphasizing that security controls must be built into application design rather than relying solely on perimeter filtering tools.
- A. Correct.
Correct. The scenario describes a classic broken access control issue, specifically an Insecure Direct Object Reference (IDOR)/Broken Object Level Authorization pattern, where changing an object reference exposes another user's data. The primary fix is application-level, server-side authorization validation for each request to ensure the authenticated user is entitled to access the referenced object. A WAF may help detect or block some suspicious requests, but it is not a reliable substitute for proper authorization logic. From a governance and risk perspective, delaying release until the control gap is remediated is the strongest response when sensitive financial and identity data is involved.
- B. Incorrect.
Incorrect. This reflects a common misconception that a WAF can fully solve authorization flaws. WAFs are useful for filtering known malicious patterns, virtual patching, rate limiting, and adding layered defense, but they generally cannot make authoritative business-context access decisions for every object request as reliably as the application itself. Attackers can often craft requests that appear normal if the core authorization logic is missing.
- C. Incorrect.
Incorrect. Database encryption protects data at rest, which is valuable for scenarios such as media theft or storage compromise, but it does not prevent an authenticated but unauthorized user from accessing data through the application if the application improperly returns it. The vulnerability exists in access control enforcement, not in storage confidentiality alone.
- D. Incorrect.
Incorrect. Base64 encoding is not a security control; it is merely an encoding format that is easily reversible. Even if the organization replaced numeric IDs with less obvious values, security through obscurity would not address the root problem. If authorization checks are absent or weak, attackers may still enumerate or replay object references and gain unauthorized access.