scan.now
Premium Scan a site

Test URL Inputs for Server-Side Request Forgery (SSRF)

Enter a page on a hostname verified in your Scan.now account. Scan.now discovers URL-like parameters in same-origin links and public GET forms, then correlates any server request to a unique short-lived callback.

Verified ownership is required. A normal page URL works when it exposes an importer, preview, webhook or fetch input; an exact parameterized endpoint remains optional.

A registered account is required to run this test. Finding status, evidence, affected locations and remediation are Premium-only. How active scanning works · Acceptable use

Confirm server-side fetching without targeting an internal address

Server-side request forgery occurs when an application fetches a user-controlled URL with more network access or trust than the user has. Image importers, webhook testers, feed previews, PDF generators and URL metadata services are common entry points.

Scan.now restricts this test to an exact verified hostname. A normal page URL is enough: the scanner discovers same-origin parameterised links and public GET forms, then places a unique, short-lived Scan.now callback URL into URL-like inputs and correlates whether the target server requests it. The probe never supplies a loopback, private, link-local or cloud-metadata address, so confirmation does not require touching an internal service.

Put this result in context

This scanner answers one part of the review. Continue with Open Redirect Scanner for check redirect and return url parameters, then API Surface Scanner for inventory api hints, openapi documents and route counts. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.

For the background behind these signals, read Website Security: What a Vulnerability Scan Looks For and How to Fix It and What Is a Vulnerability Scan? Types, Limits and What the Results Mean. The Server-side request forgery check reference explains the exact test, evidence and remediation used in the report. The Scan.now methodology explains request limits, scan boundaries and what the scanner deliberately does not attempt.

URL inputs and correlated callback evidence

The check is deliberately bounded to the signals below.

Coverage areaWhat the scanner examines
Automatic URL-input discoverySame-origin links and public GET forms are inspected for names associated with URL, source, image, avatar, webhook, callback and feed inputs.
Unique callback correlationEach authorised scan receives a short-lived random endpoint tied to the verified hostname and requesting account.
External proof onlyThe callback confirms server-side fetching while avoiding internal addresses, metadata services and port enumeration.

Confirmed fetching and absent callbacks

A scan result is evidence with a boundary, not a guarantee about every route.

Callback received

The target server made the correlated request. Treat the fetch feature as an SSRF boundary and verify destination controls, redirects and egress policy.

No callback received

No correlated request arrived during the scan window. Queued fetches, alternate protocols, blocked DNS and parameters elsewhere may remain.

Verification required

The callback probe is unavailable until the exact hostname has completed ownership verification in the account.

Destination validation and network isolation

Use the recommendations below to address confirmed findings and strengthen the surrounding control.

  1. Prefer identifiers over arbitrary URLs

    Fetch from a server-controlled catalogue or map a small provider choice to a fixed endpoint.

  2. Resolve and validate every destination

    Allow only HTTP or HTTPS, resolve DNS, reject private and special-purpose addresses, and connect to the validated result.

  3. Revalidate redirects

    Apply the complete scheme, hostname, port and resolved-IP policy at every hop rather than only to the first URL.

  4. Restrict outbound network access

    The fetch worker should reach only required public destinations and never metadata, control-plane or internal service networks.

  5. Separate the fetcher

    Run with low privilege, strict time and size limits, no ambient credentials and an isolated DNS and proxy policy.

How it works

  1. Verify the exact hostname

    Ownership verification is mandatory before Scan.now creates or supplies a callback URL.

  2. Enter the relevant verified page

    A normal page URL works when it links to or displays the importer, preview, webhook or fetch input. An exact endpoint remains optional.

  3. We correlate an external callback

    A unique short-lived URL is substituted and only a matching inbound request confirms server-side fetching.

What this tool checks

1 checks across 1 areas. Each links to its reference page with the test, the risk and the fix.

Full reference

Page content and JavaScript

1 check

The ones that most often decide the grade:

Critical Server-side request forgeryA URL-like parameter caused the verified server to request a unique Scan.now callback.

Related tools

Continue the review with four checks that cover adjacent parts of the same attack surface.

All tools
Active Security Open Redirect Scanner

Check redirect and return URL parameters
Active Security API Surface Scanner

Inventory API hints, OpenAPI documents and route counts
Active Security Path Traversal Scanner

Verify whether path-like parameters return local files
Active Security Error Disclosure Scanner

Detect exposed runtime exceptions and stack traces

Guides for this tool

Background reading written to go with these results.

13 min read · Updated Sep 13, 2026 Website Security: What a Vulnerability Scan Looks For and How to Fix It

A website vulnerability scan checks the parts of a site an attacker can reach without logging in: Transport security, HTTP headers,...

Read the guide
8 min read · Updated Sep 12, 2026 What Is a Vulnerability Scan? Types, Limits and What the Results Mean

A vulnerability scan checks a system against a list of known weaknesses and reports what matches. The types of scan, the difference...

Read the guide
8 min read · Updated Sep 14, 2026 Passive vs Active Scanning: What Each Can Find and When Each Is Appropriate

Passive scanning observes normal responses; active scanning sends crafted requests to trigger flaws. The boundary, why it matters...

Read the guide
9 min read · Updated Sep 18, 2026 How to Read a Security Scan Report: Severity, False Positives and What to Fix First

A scan report is a list of findings with severities, and the hard part is deciding what matters. How severities are assigned, how to...

Read the guide

Frequently asked questions

Does the scanner request cloud metadata or private IP addresses?

No. The probe uses a public Scan.now callback. It confirms server-side fetching without asking the target to contact loopback, private, link-local or metadata networks.

Why is hostname verification required?

SSRF testing changes a URL input and observes server behaviour. Restricting it to a proven hostname provides a clear authorisation boundary.

Can an allow-list still be bypassed through redirects?

Yes, if only the first URL is validated. Resolve and enforce the scheme, port, hostname and IP policy again at every redirect hop.

Why might an asynchronous fetch be missed?

The callback is short-lived. A queue that runs much later, requires another event or retries after the window may not be observed in this bounded scan.