A network engineer at Company ABC observes the following raw HTTP request: GET /disp_reports.php?SectionEntered=57&GroupEntered=- 1&report_type=alerts&to_date=01-01-0101&Run=…

Using HTTP instead of HTTPS is a valid concern, but it is less critical than URL-based data exposure because even adding HTTPS would not prevent session tokens and usernames from appearing in logs and Referer headers.

A short hexadecimal session ID may have insufficient entropy, but the more immediate and broadly impactful vulnerability is the direct exposure of sensitive parameters in the URL itself.

Query string parameters are recorded in plain text in server access logs, browser history, bookmarks, and HTTP Referer headers forwarded to any third-party resource the page loads. In this request, UserEntered=dsmith and SessionID=5f04189bc are both present in the URL, meaning they can be harvested from logs or leaked externally via the Referer header. This information disclosure vulnerability persists regardless of whether transport-layer encryption is applied.

Unusual date values such as 01-01-0101 could indicate an injection attempt, but the most clearly observable and impactful issue in this request is the disclosure of sensitive session and user data in the query string.