Module accesslog 

Access-log sanitisation — keeping credentials out of the request line.

The access log records path?query for every request. That is the single most useful field in it and the easiest place to leak a secret: password-reset links, magic-login links, presigned URLs, ?api_key=…, ?email=… and OAuth ?code=… all travel in the query string, and an access log is the most-copied artifact a service produces — scraped, shipped to a SIEM, retained for months, and readable by people who were never meant to hold the credential.

A proxy that advertises DLP should not be the component that writes them to disk. So the request target is sanitised before it reaches the log line, on two independent signals:

• By name — a parameter whose key is a known credential/PII name (SENSITIVE_KEYS, plus whatever the operator adds). Catches the common cases exactly.
• By shape — a value that looks like a credential regardless of what it is called: a JWT, or a long high-entropy token. Catches ?t=eyJhbGciOi…, which a name list never will.

Neither is complete on its own and the pair is not complete either; Drop is there for deployments that would rather lose the debugging value than reason about it. What is not sanitised is the path itself — /reset/<token> is indistinguishable from /users/<id> without knowing the application’s routes, and guessing would mangle ordinary paths. Applications that put secrets in path segments need Drop plus care.

Enums

QueryLogMode

What to do with the query string in the access log.

Constants

SENSITIVE_KEYS

Query-parameter names treated as credentials or personal data.

Functions

sanitize_target

Sanitise a request target (/path?a=1&b=2) for the access log.