Version: v0.1.4
Summary
When a request's source IP matches whitelistIPs, the plugin deletes both Authorization and X-API-TOKEN headers from the request before forwarding to the backend, regardless of how removeHeadersOnSuccess is configured. This silently breaks backends that use the Authorization header for their own purposes (e.g. bearer-token auth to an upstream API).
Where
plugin.go lines 536-543:
if sliceIp(*ipAddress, ka.whitelistIPs) {
logInfo.Printf(...)
req.Header.Del(ka.authenticationHeaderName) // X-API-TOKEN
req.Header.Del(ka.bearerHeaderName) // Authorization
ka.next.ServeHTTP(rw, req)
return
}
The removeHeadersOnSuccess flag is checked on the two other success paths (lines 489 and 511) but not on the IP-whitelist path.
Expected behavior
Headers should only be removed when removeHeadersOnSuccess == true. This is consistent with how the flag guards the header removal on the X-API-TOKEN and Authorization token-match paths.
Actual behavior
On IP-whitelist match, both headers are always removed even if removeHeadersOnSuccess: false. The user has no way to preserve their own
Authorization header for downstream use when relying on IP whitelisting.
Reproducer
Minimal Middleware config:
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: api-key-auth
spec:
plugin:
traefik-api-token-middleware:
authenticationHeaderName: X-API-TOKEN
tokens: ["secret"]
whitelistIps: ["10.0.0.0/8"]
removeHeadersOnSuccess: false
Request from an IP in the whitelist with an unrelated bearer token:
GET /protected
Host: example.com
Authorization: Bearer <some-backend-auth-token>
The backend receives the request without Authorization, even though removeHeadersOnSuccess is false.
Suggested fix
Guard the IP-whitelist header deletion with removeHeadersOnSuccess, matching the pattern used on lines 489 and 511:
if sliceIp(*ipAddress, ka.whitelistIPs) {
logInfo.Printf(...)
if ka.removeHeadersOnSuccess {
req.Header.Del(ka.authenticationHeaderName)
req.Header.Del(ka.bearerHeaderName)
}
ka.next.ServeHTTP(rw, req)
return
}
Version: v0.1.4
Summary
When a request's source IP matches
whitelistIPs, the plugin deletes bothAuthorizationandX-API-TOKENheaders from the request before forwarding to the backend, regardless of howremoveHeadersOnSuccessis configured. This silently breaks backends that use theAuthorizationheader for their own purposes (e.g. bearer-token auth to an upstream API).Where
plugin.golines 536-543:The
removeHeadersOnSuccessflag is checked on the two other success paths (lines 489 and 511) but not on the IP-whitelist path.Expected behavior
Headers should only be removed when
removeHeadersOnSuccess == true. This is consistent with how the flag guards the header removal on theX-API-TOKENandAuthorizationtoken-match paths.Actual behavior
On IP-whitelist match, both headers are always removed even if removeHeadersOnSuccess: false. The user has no way to preserve their own
Authorization header for downstream use when relying on IP whitelisting.
Reproducer
Minimal Middleware config:
Request from an IP in the whitelist with an unrelated bearer token:
The backend receives the request without Authorization, even though removeHeadersOnSuccess is false.
Suggested fix
Guard the IP-whitelist header deletion with removeHeadersOnSuccess, matching the pattern used on lines 489 and 511: