Ip Allow List
An ip allow list blocks all network traffic except from approved network addresses. You set it up by adding trusted office or cloud addresses to firewall rules. Engineering teams use these rules to guard databases and internal servers from outside attackers. Still, teams often add broad address ranges when remote workers change locations. Broad network rules and shared database roles let anyone on that network run risky commands. How an ip allow list works in practice A network firewall sits
IP Allowlisting / Denylisting: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An ip allow list blocks all network traffic except from approved network addresses. You set it up by adding trusted office or cloud addresses to firewall rules. Engineering teams use these rules to guard databases and internal servers from outside attackers. Still, teams often add broad address ranges when remote workers change locations. Broad network rules and shared database roles let anyone on that network run risky commands.
How an ip allow list works in practice
A network firewall sits in front of your database or internal server. When a user tries to log in, the firewall checks the source address first. If the address matches the ip allow list, the firewall lets the traffic pass. If the address is not on the list, the firewall drops the packet right away.
Teams usually route remote user traffic through a central VPN or static cloud NAT. This gives every engineer on the team the same outgoing network address. Admins then put that single shared address on the database firewall rule. Cloud providers also let admins attach security groups directly to database instances. These security groups act as a filter at the network edge before login happens.
Setting this up requires coordination between network admins and software teams. First, the team lists every server, build runner, and office network that needs database sessions. Next, the admin adds those specific CIDR blocks to the firewall rule table. Finally, the admin turns on a default deny rule to block all other internet traffic.
Managing dynamic addresses and remote teams
Static network rules work well when servers stay in one data center. Modern cloud setups and remote teams make static lists much harder to keep up. Home internet providers change user addresses without warning, which locks engineers out of tools. When an engineer gets locked out during an outage, someone must update the firewall fast.
To avoid constant lockouts, teams often open wider address blocks or shared VPN pools. Every contractor, developer, and support agent on the VPN shares the same trusted address. Once a device joins that network, the database firewall trusts all traffic from it. If an attacker steals one laptop on that VPN, they bypass the network filter too.
IP Allowlisting / Denylisting: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network rules solve and what they leave open
Network filtering is a strong first step for blocking automated internet scanners and bots. It stops outside attackers from reaching your login prompt or testing stolen passwords from home. Most security standards require network filters around production data stores and private admin ports.
Still, a network check only decides which machines can reach the login port. It knows nothing about the person typing commands or what those commands will do. Once a user logs in from an approved address, the network filter does nothing else. It cannot stop an engineer from dropping a table or reading every customer email address.
Database roles also tend to stay broad because teams share service accounts across apps. If a developer logs in with a write role, they can change any row. Network logs only show that packets moved between two addresses at a certain time. They do not record the actual SQL queries, shell commands, or API requests sent inside. Teams still need a way to check individual commands and mask sensitive fields like card numbers.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an allow list and a deny list?
An allow list blocks all traffic by default and only lets approved addresses through. A deny list lets everyone through except known bad addresses that you block by hand.
Does an ip allow list replace database user permissions?
No, network rules only control which machines can reach the database port over the network. You still need database roles and command checks to control what users do after login.
How do teams handle remote workers with changing home addresses?
Most teams route remote worker traffic through a central VPN with a fixed outgoing address. Others replace static address rules with identity checks that verify the user on every request.