HTTPS and Query Strings: What Is Actually Protected?

HTTPS encrypts query strings while they travel between the browser and the server, but that doesn't mean the information inside them is always safe. Sensitive data in URLs can still end up in browser history, server logs, analytics tools, and shared links. Understanding where HTTPS protection ends is essential for building secure web applications.

Many developers assume that when a website uses HTTPS, everything in its URL is automatically safe, including query strings such as ?token=abc123 or [email protected].

That assumption is only partly correct. HTTPS protects data while it travels across the network, but it does not prevent sensitive information from being exposed elsewhere.

Understanding where that protection begins and ends is important, especially when building applications that handle authentication, personal information, or other sensitive data.

What Is a Query String?

A query string is the part of a URL that comes after the question mark (?). It consists of key-value pairs, usually separated by an ampersand (&).

https://example.com/search?q=shoes&sort=cheapest&page=2

Query strings are commonly used for search terms, filters, pagination, and campaign tracking (UTM parameters). They are useful because they make it easy to share or bookmark a specific page state.

However, developers sometimes use them to pass sensitive information, such as authentication tokens or personal data. That's where things can become problematic.

What Does HTTPS Actually Encrypt?

HTTPS is HTTP running over TLS (Transport Layer Security). Once a secure connection is established, TLS encrypts the HTTP communication between the browser and the server.

This includes:

• The URL path (/search)

• The query string (?q=shoes&sort=cheapest)

• HTTP headers and cookies

• Request bodies

• The server's response

In other words, someone monitoring the network, such as a person connected to the same public Wi-Fi or an internet provider, generally cannot read the query string while it is being transmitted over a properly secured HTTPS connection.

However, HTTPS does not hide everything.

Depending on the connection and configuration, network observers may still see information such as the destination IP address, traffic size, and timing. Domain information may also be exposed through DNS and TLS metadata, although technologies such as Encrypted Client Hello (ECH) can reduce some of that exposure.

So, HTTPS protects the contents of the communication, but it does not make the entire connection invisible.

Where Query Strings Can Still Leak

The real problem is not necessarily how a URL travels across the network. It's what happens to that URL before, during, and after the request is processed.

Here are some common places where query strings can be exposed.

1. Browser history and bookmarks

Browsers store visited URLs, including their query strings. If a URL contains a sensitive token or personal information, anyone with access to that browser profile may be able to see it.

2. Server logs

Many web servers and reverse proxies, including Nginx and Apache, can be configured to record request URLs in their access logs.

If a URL contains an authentication token, that token may end up in logs that are retained for months or accessible to more people than necessary.

3. The Referer header

When a user navigates from one page to another, the browser may send information about the previous page through the Referer header.

Depending on the browser's Referrer-Policy, this information may include the original URL's path and query string.

Modern browsers generally use strict-origin-when-cross-origin by default. This means the full URL may be sent to pages on the same origin, while only the origin is normally sent to a different HTTPS origin.

Still, developers should not assume that sensitive query parameters will always be excluded.

4. Analytics and monitoring tools

Analytics platforms, error trackers, and monitoring services may collect page URLs as part of their data.

If sensitive information appears in those URLs, it can unintentionally become part of analytics records, debugging reports, or third-party systems.

5. Link sharing

Users regularly copy URLs and share them through messaging apps, emails, and social media.

A URL containing a token or personal information can easily end up somewhere it was never intended to go.

6. Corporate proxies and TLS inspection

Some corporate networks use TLS inspection to monitor encrypted traffic. These systems act as intermediaries that decrypt and inspect traffic before forwarding it.

When this happens, the proxy may be able to access the full URL, including its query string.

What Should Never Go in a Query String?

As a general rule, avoid putting sensitive information in URLs.

This includes:

• Passwords and PINs

• Access tokens and API keys

• Session identifiers

• Personal information such as email addresses, phone numbers, and national ID numbers

• Financial or health information

Query strings are perfectly fine for information that is safe to expose, such as search keywords, page numbers, sorting options, filters, and language preferences.

A useful way to think about it is this: if someone else gets access to the URL, would that create a security or privacy problem?

If the answer is yes, that information probably shouldn't be there.

Safer Ways to Handle Sensitive Data

There are several ways to reduce the risk of accidental data exposure.

1. Use request bodies for sensitive data

For operations that need to send sensitive information, use an appropriate HTTP method such as POST and put the data in the request body rather than the URL.

For example:

await fetch('https://api.example.com/login', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    email,
    password
  })
});

This keeps the credentials out of the URL, where they might otherwise appear in browser history, access logs, or shared links.

Keep in mind that POST does not automatically make data secure. Request bodies can still be recorded by servers, proxies, and monitoring systems. HTTPS is still necessary to protect the data while it travels across the network.

2. Send access tokens through the Authorization header

For API requests that require authentication, the Authorization header is generally a better place for access tokens.

await fetch('https://api.example.com/profile', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

This avoids exposing the token directly in the URL. However, headers can also be recorded in server logs, so sensitive headers should be excluded or redacted when logging requests.

3. Configure a Referrer-Policy

A Referrer-Policy controls how much information the browser sends through the Referer header when navigating between pages or loading external resources.

For example:

Referrer-Policy: strict-origin-when-cross-origin

This policy sends the full URL for same-origin requests but generally limits cross-origin requests to the origin.

For pages that handle particularly sensitive information, consider:

Referrer-Policy: no-referrer

This prevents the browser from sending the Referer header altogether.

4. Use short-lived, single-use tokens when URLs are necessary

There are situations where putting a token in a URL is difficult to avoid. Password reset and email verification links are common examples.

In these cases, make sure the token:

• Expires after a short period.

• Can only be used once.

• Has limited permissions.

• Is securely generated and difficult to guess.

• Is never unnecessarily recorded or forwarded to third parties.

A token in a URL should be treated as sensitive even if it is temporary.

5. Remove sensitive parameters after use

If a page receives a temporary token through a URL, remove it from the address bar once it has been processed.

JavaScript provides the History API for this:

history.replaceState(null, '', location.pathname);

This replaces the current history entry with a URL that no longer contains the query string.

However, this does not erase copies that may already exist in server logs, browser synchronization services, analytics platforms, or other systems.

6. Redact sensitive information from logs and analytics

Make sure your servers, reverse proxies, and monitoring tools do not unnecessarily store sensitive query parameters.

The same applies to authorization headers, cookies, and request bodies.

It is better to prevent sensitive information from entering logs in the first place than to discover later that it has been exposed.

7. Encode query string values properly

When constructing URLs dynamically, use URLSearchParams or encodeURIComponent to ensure special characters are represented correctly.

For example:

const params = new URLSearchParams({
  q: 'shoes & bags'
});

const url = `https://example.com/search?${params}`;

This prevents characters such as & from accidentally changing the structure of the query string.

However, URL encoding is not a security solution for injection attacks. You still need proper input validation, parameterized database queries, and output escaping depending on how the data is used.

What Happens When You Use Plain HTTP?

Unlike HTTPS, plain HTTP does not encrypt communication between the browser and the server.

This means the entire request, including the URL path, query string, headers, and request body, can potentially be read or modified by someone monitoring the network.

That makes HTTP particularly dangerous when handling authentication credentials, personal information, or any other sensitive data.

Every website should use HTTPS. It is also a good idea to configure HTTP Strict Transport Security (HSTS), which tells browsers to use HTTPS for subsequent visits.

For stronger protection on the first visit, websites can also use HSTS preload, which allows supported browsers to know in advance that a domain must only be accessed over HTTPS.

Conclusion

HTTPS protects query strings while they travel between the browser and the server, but that protection does not extend to every place where URLs may be stored, logged, or shared.

A secure connection does not guarantee that the information inside it will remain private everywhere.

Avoid putting sensitive information in URLs whenever possible. Use request bodies and authorization headers appropriately, configure your Referrer-Policy, and make sure your logging and monitoring systems handle sensitive data carefully.

Most importantly, don't assume that moving data out of the URL automatically makes it secure. Every part of an application that handles sensitive information needs to be considered, from the browser to the server and everything in between.

References

For further reading and technical details:

1. RFC 9110 – HTTP Semantics — HTTP methods, request semantics, and handling of sensitive information in URIs.

2. MDN – Referrer-Policy — How browsers control information sent through the Referer header.

3. OWASP – Information Exposure Through Query Strings in URL — Security risks associated with exposing sensitive information in query strings.