Are query strings secure over HTTPS?

HTTPS encrypts the URL path and query string in transit. It does not prevent a URL from being stored in browser history, server logs, proxy logs, or monitoring data. Systems that terminate TLS can read the request, and anyone who receives a credential-bearing URL may be able to use it.

Keep passwords and long-lived tokens out of ordinary query strings. Follow the API's authentication protocol, and protect headers and request bodies from logging too.

What transport encryption covers

A request target such as /path?key=value is part of the HTTP data protected by TLS. A passive observer cannot simply read that path or query from the encrypted connection.

The observer can still see network endpoints and traffic patterns. The hostname may be exposed by unencrypted DNS or ordinary SNI; encrypted DNS and ECH can reduce that exposure in supported configurations. TLS 1.3 also permits encrypted early data before handshake completion, so the rule is about TLS protection, not a universal claim that all HTTP data waits until the handshake finishes.

Where a URL can persist

The modern strict-origin-when-cross-origin policy normally sends only the origin on cross-origin requests, while same-origin requests can include path and query. More permissive policies can expose more. Do not assume every navigation sends the full URL, or that referrer policy removes other copies. See Referrer-Policy.

Use the intended authentication channel

Avoid a bearer token in an ordinary URL:

GET /api/user?token=abc123 HTTP/1.1

For an API using bearer authentication:

GET /api/user HTTP/1.1
Authorization: Bearer abc123

For a login endpoint using a JSON request body:

POST /api/login HTTP/1.1
Content-Type: application/json

{"username":"example-user","password":"example-password"}

These examples illustrate placement, not a complete authentication protocol. Headers and bodies also require HTTPS, access controls, and appropriate redaction. Avoid sensitive query values even in ordinary search or filter parameters; a search term can contain private information. RFC 6750 explains bearer-token transport and the risks of URI query parameters.

If secrets have already reached logs

First stop new exposure at the application or proxy. Add collection-time redaction where appropriate. Guance's local Pipeline can process logs before DataKit uploads them. Test a synthetic token in the raw message, URL, and derived fields; verify the original secret is removed everywhere, not merely copied into one redacted field.

Restrict access to historical records and remove exposed secrets through the applicable retention and incident process. Revoke and replace exposed tokens. A central Pipeline runs after upload and cannot undo the initial transfer of unredacted data.

Common questions

Why should a login form use POST if GET is encrypted too?

A GET form puts its values in the URL, increasing exposure through history, logs, and links. A POST body avoids those URL-specific paths, though the application must still avoid logging the password.

Are presigned S3 or OSS URLs an exception?

They intentionally make a URL function as a credential. Treat them as bearer credentials: use limited scope and lifetime, protect them from sharing, and account for logs that might capture them. They are not public links merely because the signature is in the query string.

Should an API key use Authorization or X-API-Key?

Use the API's documented scheme. Neither header name is inherently more secure; both require encrypted transport, least privilege, and careful logging. Read-only credentials are still credentials.