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 the API to follow any redirect so it works with more image sources.

  Why it's wrong here

  Allowing the API to follow any redirect would expand the attack surface by enabling Server-Side Request Forgery (SSRF) exploitation, as attackers could chain redirects to reach the link-local metadata endpoint 169.254.169.254 or internal admin addresses. This option is tempting because redirect following is a legitimate feature for fetching images from services that use temporary URLs, but in this scenario it directly facilitates the SSRF vector rather than mitigating it.

• ✓

  Restrict outbound requests to an allowlist and block internal address ranges.

  Why this is correct

  This is a classic server-side request forgery pattern: the server is making attacker-influenced requests to internal or metadata addresses. An allowlist of approved destinations, combined with blocking private and link-local ranges, prevents the service from being used as a proxy into internal systems. That control directly targets the unsafe outbound request behavior and is more effective than trying to clean malicious URLs after the fact. It also reduces exposure to cloud metadata theft and internal service probing.

• ✗

  Store the fetched image in encrypted form before sending it to users.

  Why it's wrong here

  Encrypting the fetched image protects data at rest but does nothing to prevent the server from making the attacker-controlled outbound request in the first place. The SSRF vulnerability occurs during the fetch, before any encryption is applied, and an attacker can still direct the server to internal endpoints like 169.254.169.254 or intranet admin panels. Encryption is a confidentiality control for stored data, not an access control for outbound connections, so it fails to address the root cause.

• ✗

  Increase the session timeout to reduce repeated logins by legitimate users.

  Why it's wrong here

  Session timeout controls only affect how long an authenticated session remains valid; they have no impact on the server-side URL fetching behavior that enables SSRF. An attacker supplying a malicious URL can trigger the request regardless of whether the user is logged in or how long their session lasts. Increasing the timeout might even widen the window for session hijacking, but more importantly, it is entirely orthogonal to the need to restrict outbound destinations.

Go deeper

Related to this question