Trusted country headers from the edge
A country header is only trustworthy if your own edge or CDN sets it. Any geo header that a client could supply can be forged, so trusting it is a security mistake. This page explains how to distinguish edge-set headers from client-supplied ones and how to handle them safely.
Trust the edge, not the client
Your edge or CDN computes a country from the connecting IP and attaches it before your application sees the request. Because it is set inside your trust boundary and overwrites anything the client sent, that value is safe to read as a coarse estimate.
A geo header that simply arrives on the inbound request — one a client could set — is different. Any client can put any country in such a header, so it is attacker-controllable input, not a fact.
Handling geo headers safely
Confirm that your edge strips or overwrites client-supplied geo headers so an inbound value cannot reach your app untouched. Read country only from the header your edge sets, and treat any other geo header as untrusted input.
This is a security note as much as a data-quality one: trusting a forgeable header can let a request misrepresent its origin to your application.
- Edge-set country header: usable coarse estimate
- Client-supplied geo header: untrusted, forgeable input
- Ensure the edge strips or overwrites inbound geo headers
How it appears in analytics and logs
A country header set by your edge is derived from the connecting IP under your control and is a usable coarse estimate. A geo header that arrives from the client is attacker-controllable input and must not be trusted.
Diagnostic use case
Decide which country header to trust by ensuring it is set by your own edge or CDN, and reject any geo value a client could have supplied.
What WebmasterID can help detect
WebmasterID relies on country signals derived at the edge under your control, not on client-supplied geo headers, so the geo it records cannot be forged by a request claiming a country.
Common mistakes
- Reading a geo header without confirming the edge set it.
- Letting client-supplied geo headers reach the application untouched.
- Treating a forgeable country header as a confirmed fact.
Privacy and accuracy notes
Even a trusted edge country header is a coarse, privacy-safe estimate, not an exact location. WebmasterID uses only edge-derived country signals and never stores raw client IPs in your analytics.
Related pages
- CDN edge country vs user country: why they differ
Many stacks derive a visitor's country from a CDN or edge header. That header reflects the network path and the edge's best estimate — not a verified user location. This page explains how edge geo headers are produced, why edge country and user country can diverge, and how to present country data honestly.
- Privacy-safe geo analytics
Privacy-safe geo analytics means using coarse country only, avoiding raw-IP geolocation, and keeping honest 'unknown' values rather than guessing. This page lays out the principles and why a coarse, honest signal is both more responsible and more trustworthy than fabricated precision.
- Website observability
Server-side signals derived inside your trust boundary.
Sources and verification notes
- MDN — HTTP headersClient-supplied headers are untrusted input; trust only edge-set values.
- OWASP — input validation guidanceTreat client-controllable headers as untrusted input.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.