IpAccessControl Security Policy

LLM-Generated Security Report Policy

Absolutely no security reports will be accepted that have been generated by LLM agents.

Exclusions

IpAccessControl should be secure by default, but it depends on correct usage. Adam Pritchard wrote an extensive post on the perils of discovering the "real" client IP. Because this module is intended for security, you should be behind a proxy that you control or trust and reading the rightmost IP in the derived remote IP address list.

The key points he makes are:

• When deriving the "real client IP address" from the X-Forwarded-For header, use the rightmost IP in the list.
• The leftmost IP in the X-Forwarded-For header is commonly considered to be "closest to the client" and "most real", but it's trivially spoofable. Don't use it for anything even close to security-related.
• When choosing the rightmost X-Forwarded-For IP, make sure to use the last instance of that header.
• Using special "true client IPs" set by reverse proxies (like X-Real-IP, True-Client-IP, etc.) can be good, but it depends on a) how the reverse proxy actually sets it, b) whether the reverse proxy sets it if it's already present/spoofed, and c) how you've configured the reverse proxy (sometimes).
• Any header not specifically set by your reverse proxy cannot be trusted. For example, you must not check the X-Real-IP header if you're not behind Nginx or something else that always sets it, because you'll be reading a spoofed value.
• A lot of rate limiter implementations are using spoofable IPs and are vulnerable to rate limiter escape and memory exhaustion attacks.

If you use the "real client IP" anywhere in your code or infrastructure, you need to go check right now how you're deriving it.

The authors of IpAccessControl have used the remote_ip plug for resolving IP addresses from proxy headers successfully in the past, but the configuration of that or a similar plug is entirely outside of the purview of this library.

Vulnerability reports should only be reported after incorrect configuration has been eliminated.

Supported Versions

Security reports are accepted for the most recent major release with support for the previous major version ending immediately.

IpAccessControl supports at most the three most recent versions of Elixir and supported Erlang/OTP versions.

As of January 2026, the support list is:

The oldest supported version of Elixir will not be deprecated until six months after the release of a new version of Elixir.

Reporting a Vulnerability

Create a private vulnerability report with GitHub.