Snipe-IT Version
v8.6.3 - build 23252-gfffcfd2a3a
How can we help?
Allow an API token to be restricted to one or more source IP ranges, set when the token is created.
A feature request, not a vulnerability report — it is a mitigation that does not exist rather than a flaw in what does.
The problem it addresses
API tokens are long-lived bearer credentials, and by their nature they end up stored in places that are not as protected as the Snipe-IT database: CI/CD variables, RMM custom fields, cron scripts, container environments, integration config files. That is what they are for, and no amount of care removes the category of risk — a token gets copied into a ticket, logged by a verbose HTTP client, or read out of a script by someone who should not have it.
Today, a token that leaves the building is fully usable from anywhere on the internet, immediately, by anyone.
The overwhelming majority of integrations, though, call Snipe-IT from a small and stable set of addresses: a NAT gateway, a CI runner pool, an office range, a single server. Letting the token say so turns a leaked credential from "usable by anyone" into "usable by anyone who is also inside your network" — which is a materially different incident.
Suggested shape
At token creation (and editable afterwards), an optional field:
Allowed source IPs (optional, comma-separated CIDR)
e.g. 203.0.113.10/32, 198.51.100.0/24
Empty means unrestricted, exactly as today, so nothing changes for existing tokens or anyone who does not want this.
Enforcement is a middleware check on the API guard: if the token has restrictions and the request's client IP is not in them, return 401/403. It needs to respect the existing trusted-proxy configuration for the client IP, since most instances sit behind a load balancer or reverse proxy — Snipe-IT already has TrustProxies handling for this, so the correct IP is available.
Why this rather than (or as well as) scoped tokens
Token scoping is the more powerful feature and I have opened #19618 for it, but it is also a much larger design conversation because it touches the permission model. This one is deliberately smaller:
- it does not change what a token can do, only where it can do it from;
- it is opt-in and defaults to current behaviour;
- it is a self-contained middleware check plus one column and one form field;
- it composes with scoping later rather than competing with it.
It is also the mitigation that actually matches how tokens leak. Scoping limits the blast radius when a credential is used correctly by the wrong person; IP restriction limits whether they can use it at all.
Prior art
This pattern is common in comparable tools — Cloudflare API tokens, GitLab personal access tokens, Atlassian API tokens and AWS IAM policies all support source-address conditions on credentials, generally as an optional field with the same "empty means unrestricted" default.
Willing to help
Happy to open a PR if the direction is welcome. I would rather check first, since it touches the API auth path and I would want to match the maintainers' preference on where enforcement lives and how it interacts with trusted proxies.
Code of Conduct
Related, filed together as a small set on API token hardening — each stands alone:
#19616 (record token usage) · #19617 (source-IP restriction) · #19618 (scoped tokens).
Snipe-IT Version
v8.6.3 - build 23252-gfffcfd2a3a
How can we help?
Allow an API token to be restricted to one or more source IP ranges, set when the token is created.
A feature request, not a vulnerability report — it is a mitigation that does not exist rather than a flaw in what does.
The problem it addresses
API tokens are long-lived bearer credentials, and by their nature they end up stored in places that are not as protected as the Snipe-IT database: CI/CD variables, RMM custom fields, cron scripts, container environments, integration config files. That is what they are for, and no amount of care removes the category of risk — a token gets copied into a ticket, logged by a verbose HTTP client, or read out of a script by someone who should not have it.
Today, a token that leaves the building is fully usable from anywhere on the internet, immediately, by anyone.
The overwhelming majority of integrations, though, call Snipe-IT from a small and stable set of addresses: a NAT gateway, a CI runner pool, an office range, a single server. Letting the token say so turns a leaked credential from "usable by anyone" into "usable by anyone who is also inside your network" — which is a materially different incident.
Suggested shape
At token creation (and editable afterwards), an optional field:
Empty means unrestricted, exactly as today, so nothing changes for existing tokens or anyone who does not want this.
Enforcement is a middleware check on the API guard: if the token has restrictions and the request's client IP is not in them, return 401/403. It needs to respect the existing trusted-proxy configuration for the client IP, since most instances sit behind a load balancer or reverse proxy — Snipe-IT already has
TrustProxieshandling for this, so the correct IP is available.Why this rather than (or as well as) scoped tokens
Token scoping is the more powerful feature and I have opened #19618 for it, but it is also a much larger design conversation because it touches the permission model. This one is deliberately smaller:
It is also the mitigation that actually matches how tokens leak. Scoping limits the blast radius when a credential is used correctly by the wrong person; IP restriction limits whether they can use it at all.
Prior art
This pattern is common in comparable tools — Cloudflare API tokens, GitLab personal access tokens, Atlassian API tokens and AWS IAM policies all support source-address conditions on credentials, generally as an optional field with the same "empty means unrestricted" default.
Willing to help
Happy to open a PR if the direction is welcome. I would rather check first, since it touches the API auth path and I would want to match the maintainers' preference on where enforcement lives and how it interacts with trusted proxies.
Code of Conduct
Related, filed together as a small set on API token hardening — each stands alone:
#19616 (record token usage) · #19617 (source-IP restriction) · #19618 (scoped tokens).