SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Allow any URL that returns a valid HTTP status code

  Why it's wrong here

  Allowing any URL that returns a valid HTTP status code fails to mitigate SSRF because the attacker only needs to reach an internal service—such as the cloud metadata endpoint at 169.254.169.254—which typically responds with HTTP 200. The check validates the response, not the destination, so internal resources that respond successfully are still exposed. Moreover, an attacker can choose URLs that return 200 for benign-looking paths, making this filter trivially bypassable.

• ✓

  Use a strict allowlist for outbound destinations and block link-local metadata addresses

  Why this is correct

  This is the best defense because the application is making server-side requests based on user input. A strict allowlist limits which external destinations the service may reach, and blocking link-local or internal addresses prevents access to sensitive metadata services and localhost resources. This directly reduces the risk of server-side request forgery in cloud environments.

• ✗

  Escape all quotation marks before sending the request

  Why it's wrong here

  Escaping quotation marks is a defense against injection flaws like SQL or command injection, where user input can break out of a syntax context. In an SSRF attack, the user-controlled URL is passed to a server-side HTTP client that resolves and fetches it; quote escaping does not alter URL resolution, DNS lookups, or network routing. The application will still request the internal address regardless of how the string is escaped, so this option does nothing to prevent the underlying vulnerability.

• ✗

  Require users to change their passwords after each upload

  Why it's wrong here

  Requiring users to change passwords after each upload is an identity and access management control that protects against credential compromise or session hijacking, not against SSRF. SSRF exploits the application's privileged position in the network to access internal resources, and password rotation does not change which destinations the application may reach. This measure is entirely orthogonal to the server-side request handling behavior and leaves the SSRF vulnerability fully exploitable.

Go deeper

Related to this question