The application determines the client IP address by directly trusting the `X-Real-IP` or `X-Forwarded-For` HTTP headers and unconditionally falling back to `request.client.host`. Because these headers can be freely modified by clients, an attacker can supply spoofed IP addresses to bypass IP-based rate limiting, tracking, or authentication. Ensure requests a
Rule Explorer
Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
- Public rules
- 4797
- Downloads
- 6.6M
- Verified
- 4797
- Authors
- 2
Extracting the leftmost IP address from the X-Forwarded-For (or similar) header by accessing index `0` after splitting by `,`. The leftmost IP address is set by the client and can be easily spoofed, leading to rate limit or authentication bypass mechanisms. Rely on the rightmost IP address added by the trusted proxy instead (e.g., `ips[len(ips)-1]`).
Unconditionally trusting the 'X-Forwarded-For' header for IP allowlisting or authentication opens the application to IP spoofing and authentication bypass. A direct attacker can forge this header. Validate the direct socket remote connection address against an explicit allowed proxies list before parsing 'X-Forwarded-For'.
Extracting the first IP address from the 'X-Forwarded-For' header can lead to IP spoofing. Load balancers like AWS ALB append the real client IP to the end of the header, leaving earlier values attacker-controlled. Extracting the first element allows an attacker to spoof their IP address by injecting their own 'X-Forwarded-For' header. Use the last IP addres
Using untrusted Host header for generating dynamic URLs can result in web cache and or password reset poisoning.
This method is part of a SOAP Web Service (JSR224). The security of this web service should be analyzed. For example: - Authentication, if enforced, should be tested. - Access control, if enforced, should be tested. - The inputs should be tracked for potential vulnerabilities. - The communication should ideally be over SSL.
This method is part of a REST Web Service (JSR311). The security of this web service should be analyzed. For example: - Authentication, if enforced, should be tested. - Access control, if enforced, should be tested. - The inputs should be tracked for potential vulnerabilities. - The communication should ideally be over SSL. - If the service supports writes (