This weakness occurs when software treats an IP address as sufficient proof of a user's identity. Because IP addresses can be spoofed, shared across multiple…
This weakness occurs when software treats an IP address as sufficient proof of a user's identity. Because IP addresses can be spoofed, shared across multiple devices on the same network, or legitimately change during a session, relying on them alone for authentication creates a serious security gap. An attacker on the same network, or one who can manipulate routing, can impersonate a legitimate user.
IP-based authentication typically appears in legacy systems or internal tools where developers assume a closed, trusted network. The code checks whether a request originates from a whitelisted IP range and grants access without requiring credentials. This pattern is flawed because:
- IP spoofing:
An attacker can craft packets with a forged source IP address.
- Shared networks:
Multiple users on the same corporate network, coffee shop, or cloud infrastructure share the same outbound IP.
- Dynamic assignment:
DHCP and mobile networks reassign IPs frequently, so the same user may appear to come from different addresses.
- Proxies and NAT:
Legitimate traffic passes through intermediaries that mask the true client IP.
The weakness is especially dangerous when combined with other design flaws—for example, if an admin panel accepts requests from 192.168.1.0/24 without further authentication, any device on that subnet can access it.
An attacker who can reach the same network segment (or spoof an IP) gains unauthorized access to sensitive functions: viewing user data, modifying configurations, executing administrative commands, or pivoting to other systems. In cloud environments, this can mean lateral movement between tenants. Even in air-gapped networks, a compromised internal device becomes a foothold for privilege escalation.
from flask import Flask, request
app = Flask(__name__)
TRUSTED_IPS = ["192.168.1.100", "10.0.0.50"]
@app.route("/admin/users")
def list_users():
client_ip = request.remote_addr
if client_ip in TRUSTED_IPS:
return get_all_users()
else:
return "Forbidden", 403Why it's vulnerable:
The code grants full access based solely on IP address, with no credential verification. An attacker on the same network or one who spoofs the IP can bypass this check entirely.
from flask import Flask, request, session
from functools import wraps
app = Flask(__name__)
app.secret_key = "your-secret-key"
def require_login(f):
@wraps(f)
def decorated_function(*args, **kwargs):
if "user_id" not in session:
return "Unauthorized", 401
return f(*args, **kwargs)
return decorated_function
@app.route("/admin/users")
@require_login
def list_users():
return get_all_users()<?php
$trusted_ips = ["192.168.1.100", "10.0.0.50"];
$client_ip = $_SERVER["REMOTE_ADDR"];
if (in_array($client_ip, $trusted_ips)) {
// Grant admin access
$_SESSION["is_admin"] = true;
echo "Admin panel loaded.";
} else {
http_response_code(403);
echo "Forbidden";
}
?>Why it's vulnerable:
Access is granted based only on IP matching, with no password, token, or session verification. This can be bypassed by spoofing or by any user on the trusted network.
<?php
session_start();
if (!isset($_SESSION["user_id"]) || !isset($_SESSION["is_authenticated"])) {
http_response_code(401);
echo "Unauthorized";
exit;
}
// Verify user credentials were validated during login
if ($_SESSION["is_authenticated"] === true) {
echo "Admin panel loaded.";
} else {
http_response_code(403);
echo "Forbidden";
}
?>Secure and HttpOnly.
Review your application logs and access controls for patterns like IP-based grants without credential checks. Look for admin panels, API endpoints, or internal tools that check REMOTE_ADDR or X-Forwarded-For headers without verifying a session token or password. If you find code that says "if IP is in this list, allow access," that is a red flag.
