Skip to content

Authorization Request Header Injection

Authorization Request Header Injection is a vulnerability that arises when an application or gateway interprets user-supplied input—specifically the Authorization header—in a way that allows a client to bypass security checks. This technique exploits the precedence rules of authorization systems within service meshes like Istio or proxies like [[Envoy]], potentially allowing unauthorized requests to be forwarded to backend services.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md]

Mechanism of Action

In typical implementations, an external authorization filter (such as the Envoy ext_authz filter) sits in front of a service to validate incoming requests.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md] The injection vulnerability occurs when the gateway incorrectly determines the scope of the authorization check. Specifically, the gateway may treat the client's Authorization header as intended for the external authorization service (the filter) rather than the upstream backend service.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md]

If the external service is configured to check for a specific token or allow-listed service account, and the client provides a valid credential for that specific check, the filter permits the request.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md] The filter then forwards the request to the backend application, inadvertently including the original Authorization header. Since the backend service may recognize this header as a valid credential (e.g., a bearer token or JWT), the client successfully authenticates with the internal application despite not having the original intent of the filter to authorize this specific backend access.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md]

This issue is essentially a confusion regarding the "audience" of the credentials: the filter validates the token for itself, and the backend validates it for itself, but the gateway fails to distinguish between the two contexts, allowing a single header to satisfy both checks unintendedly.^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md]

  • Istio
  • [[Envoy]]
  • [[External Authorization]]
  • [[Authentication vs Authorization]]

Sources

^[400-devops-07-monitoring-and-observability-k8s-istio-samples-extauthz-readme.md]