Start by identifying whether a user-supplied URL makes a server-side component request a destination. Record which component performs that request and what evidence supports the description. A URL field alone does not demonstrate an exploitable server-side request forgery (SSRF) vulnerability. Equally, an automation that returns no fetched content has not thereby demonstrated safety. The worksheet below organizes a defensive design review; it is not a scan or protection assessment.
Separate the fetch boundary from configuration context
OWASP API7:2023 describes SSRF involving an API endpoint accessing a client-provided URI. It distinguishes attacks with response feedback from blind SSRF, where that feedback is absent. Possible consequences include internal-service discovery, information disclosure, bypassing security mechanisms and denial of service. These are potential consequences, not findings about your automation.
OWASP API8:2023 addresses broader configuration problems across network and application layers, including insecure defaults and unnecessary services. Configuration weaknesses can expose sensitive data or system details. API8 supplies context for reviewing the surrounding environment; it does not establish that a particular URL-taking workflow has SSRF.
A copyable server-fetch boundary worksheet
This is a proposed editorial method, not an OWASP checklist. Complete one record for each distinct fetch path. Attach an evidence reference and its date to each answer; use unknown rather than assuming a blank means no exposure.
| Field | What to record |
|---|---|
| User-supplied destination | URL input: ___; who supplies it: ___; which destination parts they can influence: ___. |
| Server-fetch component | Component making the request: ___; owner: ___; evidence that a server-side request occurs: ___. |
| Possible network or data exposure | Destinations or data potentially exposed: ___; documented boundaries: ___; unsupported possibilities to investigate: ___. |
| Response visibility | What the submitter receives: ___; what other feedback is documented: ___; what remains unknown: ___. |
| Evidence available | Design record, implementation reference or existing authorized observation: ___; date and scope: ___. |
| Redirect behavior | Whether redirects occur and which component handles them: ___; evidence: ___. Leave unanswered if undocumented. |
| Unresolved questions | Missing answer: ___; responsible owner: ___; evidence needed before the next design decision: ___. |
Keep possible exposure separate from demonstrated reachability. Writing “internal destination might be reachable” identifies a question, not a confirmed finding. Likewise, naming a component does not establish its effective network permissions. Ask the responsible owner for evidence rather than filling those gaps with assumptions.
Choose a review disposition—not a safety badge
- Server fetch documented: continue the boundary review. Record the component, destination influence and unresolved exposure questions. This establishes a review path, not exploitability.
- Fetch path unknown: leave the decision unresolved and request architecture or implementation evidence. Do not mark the worksheet passed.
- Only a browser-side request documented: record that limited finding. It does not answer whether another service fetches the URL later.
- No response content returned: keep the server-fetch question open. Missing feedback is not a sufficient reason to close an SSRF review.
Redirect handling needs its own unanswered entry because the supplied excerpts do not establish how any automation follows redirects or which specific controls would be effective. Do not turn this worksheet into a mitigation recipe. Any verification involving requests should be separately authorized and scoped; the worksheet itself does not authorize probing systems.
Hypothetical example: an AI summarization workflow
Suppose a user submits a document URL and receives only a task identifier. A design note names a background fetch worker, but provides no redirect or network-boundary details. Record the worker as documented design behavior, the task identifier as the described response, and the remaining fields as unknown. The next step is to obtain the missing evidence from the worker’s owner—not to infer either protection or a successful attack.
Keep the record useful and current
For a related ownership record, use the API inventory and retirement checklist. An inventory supports locating components and owners; it is not an SSRF defense by itself.
Source scope: the supplied API7 capture is dated 2026-10-23T21:36:46.324458+00:00; the API8 capture is dated 2026-10-23T21:36:46.657895+00:00. These are captures of OWASP’s 2023 edition explanations, not new checks of your system or live availability. No implementation was inspected or tested for this article. Revisit the worksheet when destination handling, fetch components, network boundaries, response behavior, redirects or relevant configuration changes; refresh source-dependent conclusions if the official guidance changes.
