Your logs say the request came from 203.0.113.50. Your rate limiter keyed off that address. Your "block this IP" rule just punished someone who may not have sent a single byte.
The source IP address is normally the address that the packet was sent from, but the sender's address in the header can be altered, so that to the recipient it appears that the packet came from another source. That is IP spoofing in plain terms. The header field is not a cryptographic proof of origin. It is a label the sender (or an intermediate party in some designs) writes down.
Why that matters before you touch "trust this IP"
For many protocols, especially UDP and raw IP, nothing stops a host from putting another address in the source field. The internet forwards packets based on routing, not on whether the source field "matches" the real origin in some global registry. Receivers often believe the label because it is useful for replies and logging, not because it is verified end to end.
TCP is a partial exception for full connections: you cannot complete a normal three-way handshake if you pretend to be someone else, because the victim of the impersonation gets the SYN-ACK, not you. Spoofed TCP still shows up in scans, SYN floods, and weird edge cases, but "I opened a socket as 8.8.8.8" is not how everyday app traffic works. UDP and ICMP are the usual playgrounds for forged sources because there is no equivalent handshake tying the session to the real sender.
Where builders actually meet this
Amplification and reflection. Attackers send small requests with a forged victim source IP. Open resolvers, NTP servers, memcached instances, and other UDP services reply to the victim, not to the attacker. The victim sees a flood "from" those services. The original packets were spoofed; your logs at the victim show reflector IPs, not the bot that started it.
Blind injection and smokescreens. Even when an attack does not need reflection, a forged source can confuse defenders, pollute blocklists, or bypass naive IP-based rules if something upstream rewrites headers inconsistently.
Application trust mistakes. Your app might read X-Forwarded-For or similar headers and treat the leftmost value as "the user." Proxies and clients can lie. Spoofing at the IP layer is different from header spoofing at HTTP, but the lesson is the same: an IP string is a hint, not an identity.
Coarse signals still have a place. IP can be useful for broad rate limiting, geo hints, and tying abuse bursts together in the short term. The failure mode is not "never look at IP." The failure mode is treating IP as proof of who someone is, or as a permanent ban anchor, without corroboration.
What to do about it (practical, not preachy)
1. Do not use IP alone for authentication or sensitive authorization. If "admin allowed from this IP" is your control, assume it will break or be abused. Use real auth, device-bound sessions, and network controls that do not pretend an IP is a person.
2. Understand what your platform actually sees. Behind load balancers and CDNs, the meaningful address is often in a trusted header your edge sets, not in the raw socket. Configure trusted proxy hops and parse forwarding headers only from those hops.
3. For abuse handling, combine signals. Rate limits, fraud scores, and blocks work better with behavior, accounts, fingerprints, and shared intelligence than with a single volatile field.
4. If you operate UDP services, harden for the internet you have. Disable open recursion, close unnecessary ports, and follow BCP38-style guidance where you control edge networks so you are not part of someone else's amplification story.
Bottom line
Spoofing works because the IP header's source address is declarative, not attested. Packets carry what the sender put there. For connection-oriented TCP to your app, the session usually still ties to a real peer, but UDP, ICMP, and misread HTTP metadata still train-wreck teams who treat "the IP" as ground truth.
Build and defend like the label might be wrong, because sometimes it is.
---
Sign up for automated security testing that traces real application behavior, not just the obvious entry points: https://panel.axeploit.com/signup
