IP whitelisting mitigated a critical security issue
IP whitelisting is old-school. But it’s also a simple way to add a surprisingly strong second layer of defence. Here’s how it saved us during a security audit.
The mistake: Trusting the Host header
We had a vulnerability in the “Forgot password” feature for admin users. When a user requested a password reset link, the application used the HTTP Host header to determine which domain (staging or production) to use in the link that was emailed to the user.
This is a classic mistake: you should never trust the Host header as it can be forged by an attacker.
By forging the header, an attacker could generate a reset link pointing to their own domain:https://evil-domain.io/api/auth/password-reset?token=.... Since the email only showed “Reset your password” button, it wasn’t obvious that the link had been tampered with. If the admin clicked it, the secret token was sent to the attacker.
The second layer to the rescue
We had implemented a “Defense in Depth” strategy and all admin endpoints (/api/admin/*) were protected by IP whitelisting. Only traffic coming from our office VPN was allowed through.
The attacker could have successfully hijacked the token and reset the password, but they still couldn’t perform any admin actions. Their IP wasn’t on the whitelist.
During the security audit, the issue was downgraded from critical to high because of this safeguard. It was still bad, but contained.
“But IPs can be spoofed”
Technically, yes, but spoofing is practically useless in this situation:
The attacker doesn’t know the correct IP. Guessing a specific IPv4 address is impractical, and our rate-limit makes it almost impossible.
Spoofing breaks the response path. TCP/IP protocol works so that the server’s response goes to the spoofed IP address, not back to the attacker. So while they could send blind
POSTandDELETErequests without knowing if they succeeded, they wouldn’t receive any sensitive data back.
Simply: the data can’t leak. That eliminates a massive attack vector.