Yes. The predefined combined format logs the full request line, which includes the query string, and the Referer header. It does not log the Authorization header unless you add it. Any token placed in a URL will therefore end up in your access logs.
What the default format contains
The nginx log module documents the predefined combined format like this:
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
Variable by variable:
| Variable | Contains | Sensitivity |
|---|---|---|
| remote_addr | Client IP | Personal data in many regimes |
| remote_user | Username from HTTP authentication | Identifies a person |
| request | Method, full URI with query, protocol | May hold tokens, emails, reset codes |
| http_referer | The Referer header | Can carry the previous page's URL and query |
| http_user_agent | Browser string | Low |
The Authorization header and other request headers are not in the format. Logging them takes a custom format that uses the http_authorization variable, so do not add that variable.
Where the risk really is
Two fields carry most of the danger. The request line includes whatever the client put after the question mark: API keys, password reset tokens, magic login links, signed download URLs. The Referer field can include the same kind of values from the page the user came from.
Once written, those values sit in a file, are shipped to a central store, and are readable by everyone with log access. The secret has been copied three or four times before anyone reviews it.
Steps to log less
- Search recent logs for patterns such as token=, key=, secret=, code= and password=. Count the hits.
- Fix the clients. Credentials move into the Authorization header or a request body. See bearer token in header or query string.
- For endpoints that must carry a token in the URL, such as a one-time reset link, log a separate custom format for that location that records the path without the query. In nginx, the uri variable holds the path without arguments, while args holds the query.
- Decide whether you need the Referer at all. If not, remove it from your custom format.
- Short retention on raw access logs, longer retention on a reduced version. See set log retention by data class.
- Add a redaction layer in your shipper as a second defence.
A sample reduced format
log_format reduced '$remote_addr [$time_local] "$request_method $uri" '
'$status $body_bytes_sent "$http_user_agent"';
This keeps method, path, status and size, which is enough for most security triage, and drops the query string and Referer. You lose some debugging detail, so test with your support team before you roll it out. The nginx page defines the variable names above, but you should confirm uri and args behaviour against your nginx version.
Quick check
Does the combined format log the Authorization header?
No. It records Referer and User-Agent from request headers. You would have to add the Authorization variable yourself, and you should not.
Is the IP address in the log personal data?
Often yes. See is an IP address in a log personal data under GDPR.
Safeguard scans dependencies and builds SBOMs, so you can see which web server and proxy components you ship. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
