# Trusted client identity headers spoofing

Client-supplied identity headers or encoded blobs trusted as authenticated identity by proxy or backend

_Area: Web access control and IDOR. Seen in 2 disclosed reports; latest 2026-09-18. Updated 2026-10-24._

## How it works
A proxy or handler is supposed to establish who the caller is, then pass that identity to a backend. The assumption that breaks: the backend treats every identity-bearing value it receives as having been set by the trusted proxy. When the client can also supply that value — in a connect message, a request header, or an encoded parameter — the backend cannot tell the proxy's assertion from the client's forgery, and accepts the client's version.

## Where it shows up
- A `headers`/`metadata` map inside a client-sent protocol message that is copied into the context forwarded to a proxy backend [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md).
- Proxy code that appends its identity headers (`X-Remote-User`, `X-Remote-Group`, `X-Remote-Extra-*`) to inbound requests instead of replacing them [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-c8w2-fgvx-vhv4.md).
- Backends that trust all copies of an identity header arriving over a proxy connection [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-c8w2-fgvx-vhv4.md).
- Base64-like parameters carrying a recipient or identity field, with odd padding (e.g. trailing `.` instead of `=`) [E2](https://bugbountylibrary.com/r/blog%3Aavatao-com-blog-how-i-could-have-stolen-your-photos-from-google-my-first-3-bug-bounty-writeups.md).
- Documentation claiming to forward "incoming HTTP headers" where the real source is the client's own message [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md).

## How to review
Trace each identity value from wire to authorization decision. The invariant: every identity field the backend trusts must originate from the proxy's own authentication step, never from client-controlled input. Check that the proxy strips or overwrites the entire identity header namespace before adding its own, and that the backend rejects or ignores duplicates. For protocol messages, confirm the forwarded headers come from transport-level HTTP headers, not from a field in the client's connect payload [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md). For encoded parameters, decode them and verify the server checks the victim actually intended to share with the embedded account [E2](https://bugbountylibrary.com/r/blog%3Aavatao-com-blog-how-i-could-have-stolen-your-photos-from-google-my-first-3-bug-bounty-writeups.md).

## Variants seen
- Client-supplied headers map in a connect message forwarded as emulated headers to proxy backends [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md).
- Proxy appending rather than replacing inbound identity headers, letting any tenant forge `system:masters` [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-c8w2-fgvx-vhv4.md).
- Encoded request parameter carrying a trusted recipient email without consent verification [E2](https://bugbountylibrary.com/r/blog%3Aavatao-com-blog-how-i-could-have-stolen-your-photos-from-google-my-first-3-bug-bounty-writeups.md).

## Impact and severity
Forged identity let any authenticated client impersonate a privileged group and reach every workspace on a shard [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-c8w2-fgvx-vhv4.md), and let any client spoof trusted identity headers to backends [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md). Severity is high because the attacker needs only ordinary authenticated access; it worsens when the forged identity maps to a cluster-wide or cross-tenant role, and when the backend trusts all header copies rather than one.

## Evidence
- E1: https://bugbountylibrary.com/r/ghsa%3AGHSA-9468-v6mj-fppw.md
- E2: https://bugbountylibrary.com/r/blog%3Aavatao-com-blog-how-i-could-have-stolen-your-photos-from-google-my-first-3-bug-bounty-writeups.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-c8w2-fgvx-vhv4.md