scan.now
Premium Scan a site

Find Session IDs and Access Tokens Exposed in URLs

Enter a page or parameterised URL. Scan.now checks the entered address and discovered GET forms for session IDs, access tokens and similar credentials placed in query strings.

Enter the exact public page to inspect. No form is submitted and no data is modified.

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

Why credentials do not belong in a URL

URLs are copied into browser history, server and proxy logs, analytics systems, screenshots, support tickets and sometimes Referer headers. A session ID, access token or JWT in the query string therefore escapes the narrow channel intended for authentication and can remain recoverable long after the request ends.

Scan.now checks the entered URL and discovered public GET forms for parameter names strongly associated with sessions and access tokens. Values are not included in the finding. This is a naming and placement check: an unusual custom credential name can be missed, while a harmless field called token may require human review.

Put this result in context

This scanner answers one part of the review. Continue with CSRF Scanner for inventory post forms and recognisable anti-csrf fields, then Open Redirect Scanner for check redirect and return url parameters. 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 Session token exposed in URL 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.

Where exposed credentials can appear

The check is deliberately bounded to the signals below.

Coverage areaWhat the scanner examines
Entered addressSession-like names in the exact URL are detected without reproducing or storing their values in evidence.
Discovered GET formsPublic forms that would place auth, access_token, jwt, sid or similar fields in a query string are included.
Exposure channelsThe result explains the browser, log, analytics and referrer paths that make URL credentials unusually persistent.

Named token parameters and clean URLs

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

Session-like name found

Determine whether the value grants access. If it does, stop issuing it in URLs and rotate every exposed token.

No session-like name

No recognised credential parameter appeared in the entered address or discovered GET forms. Custom names and JavaScript-generated URLs may remain.

Needs classification

Fields named token or auth can be one-time non-secrets. Confirm purpose, lifetime, audience and replay behaviour before assigning severity.

Cookies and headers for safer authentication

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

  1. Use secure cookies for browser sessions

    Set Secure, HttpOnly and an appropriate SameSite policy, with a narrow Domain and Path.

  2. Use the Authorization header for APIs

    Bearer credentials belong in a header over HTTPS, not in query strings, route segments or fragments.

  3. Make unavoidable links single-use

    Email verification and reset links need short expiry, one-time consumption, narrow purpose and redaction from logs.

  4. Redact at every logging layer

    Configure the CDN, load balancer, application, monitoring and analytics pipeline to remove secret parameters.

  5. Rotate what has already leaked

    Moving future tokens is not enough; assume existing histories and logs retain old URLs and revoke them.

How it works

  1. Enter the relevant page or URL

    Use the page that creates links or GET forms, or paste the parameterised address directly.

  2. Credential-shaped names are inventoried

    Values are excluded while common session and access-token parameter names are identified.

  3. Trace and rotate

    The report explains likely exposure channels and the safer transport for each credential type.

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

Cookie security

1 check

The ones that most often decide the grade:

High Session token exposed in URLA session-like token name appears in a discovered URL.

Related tools

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

All tools
Active Security CSRF Protection Scanner

Inventory POST forms and recognisable anti-CSRF fields
Active Security Open Redirect Scanner

Check redirect and return URL parameters
Active Security XSS Vulnerability Scanner

Confirm reflected script injection in a URL parameter
Websites Security Headers Checker

CSP, HSTS, frame and MIME policies

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

Is an HTTPS URL private?

HTTPS protects the request while it travels over the network. The complete URL can still be stored by the browser, application, reverse proxy, analytics and anyone a user copies it to.

Are URL fragments safer than query strings?

Fragments are normally not sent in the HTTP request, but browser scripts, extensions, screenshots and copied links can still expose them. Long-lived credentials should use cookies or Authorization headers.

Are password-reset links vulnerabilities?

Not automatically. They are an accepted URL-secret pattern when they are random, single-use, narrowly scoped, quickly expired and kept out of third-party requests and logs.

Does the report store the token value?

No. The finding records the parameter name and location needed to fix the design, not the credential value.