X-Forwarded-For trusts the wrong (spoofable) hop

Rate limiting exists to protect the business from abuse -- credential stuffing on login, scraping, or a single bad actor consuming disproportionate infrastructure cost. A key-derivation bug that lets an attacker pick a fresh "identity" per request defeats that protection entirely, for every rule keyed by IP. Concretely: the login-brute-force-guard rule becomes decorative and any IP-based abuse mitigation elsewhere in the product inherits the same hole. This is a security control that looks like it's working (metrics show denials happening, dashboards look normal) while silently protecting against nothing for anyone who bothers to read the header-splitting logic -- exactly the kind of gap that shows up in a security audit or, worse, in an incident postmortem.

KeyByIP's doc comment says it prefers "the leftmost hop in X-Forwarded-For (set by a trusted upstream proxy)." The implementation does not do that anymore -- it picks a different entry than documented.

req := httptest.NewRequest("GET", "/", nil) req.Header.Set("X-Forwarded-For", "203.0.113.7, 10.0.0.5") key := middleware.KeyByIP(req) // got: "10.0.0.5" // want: "203.0.113.7"

This isn't just cosmetic -- it's a rate-limit bypass. If the key used for rate limiting is influenced by a hop an attacker can control (any value they put in X-Forwarded-For themselves, if your edge proxy doesn't strip and overwrite the header before forwarding), and the code picks a different position than the one your trusted proxy actually appends, an attacker can manipulate the number of comma-separated segments they send to control which "key" they get rate-limited under -- effectively picking a fresh identity per request and evading the limiter entirely.

Look at exactly which slice index is being read out of the comma-split header value, and compare it against what the doc comment promises ("leftmost"). Fix the index, not the splitting/trimming logic (which is otherwise correct).