ip_access_control

# 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][xff]. 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`][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][otp-versions].

As of January 2026, the support list is:

| Elixir | Erlang         |
| ------ | -------------- |
| 1.17   | 25, 26, 27     |
| 1.18   | 25, 26, 27, 28 |
| 1.19   | 26, 27, 28     |

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][advisory] with GitHub.

[advisory]: https://github.com/KineticCafe/ip_access_control/security/advisories/new
[otp-versions]: https://hexdocs.pm/elixir/compatibility-and-deprecations.html#between-elixir-and-erlang-otp
[remote_ip]: https://hexdocs.pm/remote_ip/
[xff]: https://adam-p.ca/blog/2022/03/x-forwarded-for/