A library feature fetches a user-supplied URL from the application server to generate link previews. What vulnerability class should the tester investigate first?
Select an answer to reveal the explanation.
Short Explanation
When the server itself runs errands you typed, it might visit rooms you should not reach. That is SSRF — server-side request forgery toward internals or cloud metadata. Huge theme in modern apps; classify it without a payload dump.
Full Explanation
SSRF should be investigated first when a library feature fetches a user-supplied URL from the application server to generate link previews. Server-side requests inheriting the app’s network trust may reach internal services or cloud metadata endpoints—classic SSRF impact for municipal application hosts that can see more than the public internet.
Client-only open redirect that never leaves the browser is a different class. Missing logo alt text and weak DKIM on newsletters are unrelated distractors.
Exam caveat: SSRF defenses include allowlists, block private/metadata ranges, and avoid returning raw internal responses. CPTS web methodology prioritizes SSRF on preview/webhook/import URL features.
Operational check: probe only RoE-approved internal/harmless targets or use safe callback listeners, restrict preview fetches to allowlisted schemes/hosts, block link-local/metadata IPs, and verify the library app cannot reach internal admin URLs via preview. Link-preview workers should run with reduced network egress policies so SSRF, if it reappears, cannot freely reach cloud metadata or internal admin URLs. Egress allowlists on preview workers are practical SSRF mitigations for library link features.