How query parameters appear in server logs

A browser asks a web server for a resource by sending a request line to the host named in the address. The line contains the path and, when present, a query string. For an Australian online shop, a request might appear as GET /winter-sale?plan=standard&utm_source=email HTTP/1.1. Everything after the first question mark is the query string; the path ends immediately before it. A query parameter is normally written as a name and value separated by an equals sign.

Server logs are plain-text records of those requests. A simple site whose “Click here” link redirects to the same domain with a tracking-style suffix can therefore leave two related entries: one for / and another for /?click_id=abc123. The suffix may look trivial, yet it can connect visits, reveal campaign details or expose more than its author intended.

Where the parameter sits in the request

A typical access log preserves the full request target, including the suffix. A line such as GET /search?q=rain+forecast&city=melbourne HTTP/1.1 tells the application that the visitor requested the /search route, with two parameters: q and city. If the route does not exist, the same visible parameters remain in the access record even though the server returns a 404 response.

A query string usually begins with ?. An equals sign divides the name from its value, and an ampersand separates adjacent pairs. Repeated names are valid, although their order may differ between systems. Spaces and reserved characters are often percent-encoded: %20 represents a space, while %3F represents a question mark. The access log may retain that encoded text while an application decodes it before using the value.

The fragment, beginning with #, is different. A browser keeps it for client-side navigation and does not transmit it in the HTTP request, so it will not appear in a standard access log. Parameter order is not usually meaningful to the application, but a cache key or analytics pipeline may preserve the exact order. That makes two otherwise similar requests easy to distinguish in the record.

Tracking parameters in everyday traffic

Many parameters are deliberately added for measurement. The familiar utm_source, utm_medium, utm_campaign, utm_content and utm_term names describe where traffic originated and which message produced it. Advertising systems also use click identifiers such as gclid, fbclid and msclkid, while publishers and affiliates may use ref, affiliate or click_id. These labels are conventions, not guarantees of accuracy.

For instance, a request to the linked guide could therefore carry something like ?utm_source=partner&utm_medium=referral&campaign_id=48. The visible line confirms which suffix arrived, but it does not prove that a person came from that partner; referrer data, redirects and consent settings must be checked too. The same caution applies when a shortened link expands into several query parameters.

Other parameters are functional. A site may put a search term, store postcode, support ticket, email address or return URL in the suffix. A suburb name in a store locator can become personal information when combined with an IP address, device details and time of access. A random-looking identifier may still be a pseudonymous profile that an organisation can link back to a person.

Reading common log formats

Apache’s combined format places the request target inside quoted fields, followed by status and byte count. A representative entry is 192.0.2.45 ... "GET /search?q=rain+forecast&city=melbourne HTTP/1.1" 200 1834. The query is plainly visible there. The referrer field can also contain another site’s query string, so a log line may show tracking data entering from a third-party page as well as data sent to the current route.

Nginx commonly exposes the same text through its $request variable, while structured JSON logs may split it into request_uri, query_string and args. Reverse proxies, content delivery networks and web application firewalls may keep separate records, and some services deliberately omit the full query. A blocked request can therefore be visible in a firewall log but absent from the origin server’s access file.

Time zones need equal care. Many log formats use DD/MMM/YYYY:HH:MM:SS and an offset from UTC. Most Sydney and Melbourne servers use +1000 in standard time and +1100 during daylight saving; Adelaide generally uses +0930 or +1030. Brisbane does not observe daylight saving. Some services store UTC with a Z suffix instead. During an incident, a support team must convert the timestamp rather than assume every line uses Australian Eastern Time.

Privacy duties under Australian law

The Australian Privacy Act 1988 and the Australian Privacy Principles apply to covered organisations and government agencies. Coverage and the relevant exceptions depend on an entity’s size, activities and the kind of information involved, so a small business should not assume it falls outside the Act simply because it is small. When query data is collected, its purpose and notice should be handled under the applicable rules, not treated as anonymous debugging debris.

The Office of the Australian Information Commissioner emphasizes that IP addresses and online identifiers can be personal information in relevant circumstances. An email address, phone number, account reference or precise location embedded in a URL may also disclose personal information. Covered entities must apply the Principles, including transparency, collection limitation, security safeguards and mechanisms for accessing and correcting information.

Commercial use brings additional Australian rules into view. If an online retailer extracts ?email=... from a request and adds that address to a marketing audience, the Spam Act 2003 may require consent, clear sender identification and a working unsubscribe mechanism, subject to the Act’s exceptions. Logging policy should name the applicable rules rather than promise that “privacy” has been handled automatically.

Security risks visible in the line

A URL suffix can spread beyond the server that received it. It appears in browser history, bookmark files, copied links and reverse-proxy logs, and it may also be exposed in an outgoing Referer header depending on the site’s referrer policy. Screenshots and support tickets often capture it as well. A password or reusable access token placed in the query is especially risky because it often survives in retained logs and may be copied into other systems.

A parameter is not code by itself, yet its value can become dangerous when copied unsafely into a shell command, SQL statement, log message or template. Parameterised database queries, allowlisted values, context-appropriate output encoding and argument arrays prevent one request from changing the meaning of another operation. Newlines and control characters should also be stripped before a value is written to a log, preventing forged log lines.

The Australian Cyber Security Centre’s Essential Eight and related log-management guidance treat logging as part of detecting compromise, finding weaknesses and supporting incident response. Access to raw files should be limited to staff who need it, copies should be protected from tampering, alerts should flag unusual bursts or suspicious parameters, and exposed secrets should be rotated. These controls apply whether a service runs in a Sydney data centre or a small business’s office.

A practical investigation workflow

Start with a known time window, request path and response status, then preserve the raw line before interpreting it. The IP address can help locate traffic across servers, but it should not be treated as proof of identity: carrier allocation, corporate proxies, VPNs and mobile networks complicate attribution. A path may also be normalised differently by a proxy and the application, so compare both forms rather than assuming one is wrong.

For a plain-text log, a command such as grep 'GET /search' access.log can isolate candidates. JSON logs support structured filters; for example, jq -r 'select(.request_uri | contains("?")) | [.timestamp, .request_uri, .status] | @tsv' access.json can print the relevant fields. Field names and types vary, so inspect one record first and adapt the expression. Sensitive values should remain in a restricted environment while the investigation proceeds.

Next, compare the original request with any redirect, application event or analytics hit it generated. A 302 response followed by a 200 entry may represent the final page, while a rewritten cache key can conceal the original suffix. During a handover between Sydney and Melbourne support desks, document whether timestamps are UTC, local or daylight-saving time and record each timezone conversion. That prevents a harmless minute-level discrepancy from becoming the focus of an incident.

Retention, sharing and sensible defaults

A useful retention period follows a documented purpose. Raw request logs may be needed briefly to diagnose a checkout or login fault, while aggregated security signals may justify a different schedule. Define deletion dates, restrict access, encrypt copies and record who can export them. Keeping every query forever can turn an ordinary operational system into an unnecessarily searchable repository of customer details.

Redaction often works better than blanket deletion. Keep campaign fields needed for analysis while removing email addresses, session values and free-text search terms at ingestion. Where correlation is necessary, a rotating salted hash can group requests without retaining the original value, although the mapping must remain protected. Analytics and CDN vendors may receive a broader query string than the origin application, so check those pipelines separately.

Australian organisations commonly buy logging, CRM and CDN services in a local market where invoices may be in Australian dollars, but billing currency does not determine where data is stored or which privacy law applies. For staff education, an internal wiki can point to this reader resource alongside the logging policy, provided the external site passes the organisation’s normal security and content review. The most useful record keeps enough context to diagnose a request without preserving unnecessary personal detail.