Web Access Control List
You set up a web access control list by writing ordered traffic rules. These rules allow, block, or count incoming requests at the network edge. Teams use this list to protect public apps from bad bots and attacks. Broad rules let bad traffic through or block real users by mistake. Tight rules take care to write and test before you turn them on. How a web access control list works A web access control list sits in front of your public web app. Every incoming request hits this rule list before
Web-Based Terminal Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a web access control list by writing ordered traffic rules. These rules allow, block, or count incoming requests at the network edge. Teams use this list to protect public apps from bad bots and attacks. Broad rules let bad traffic through or block real users by mistake. Tight rules take care to write and test before you turn them on.
How a web access control list works
A web access control list sits in front of your public web app. Every incoming request hits this rule list before it reaches your backend servers. The list holds a set of rules that you sort by priority number. The system reads each request and checks the rules from top to bottom. Each rule looks at specific parts of the incoming web request. It can check the source IP address, the country, or the request headers. It can also look at the URL path, query strings, or body text. When a request matches a rule, the system takes the set action right away. It can allow the request to pass or block it with an error. Many teams also use a count action to test new rules first. Counting logs the match without blocking the user, so you can spot mistakes. If a request matches no rules, the list applies a default fallback action. You set this default action to either allow all or block all traffic.
Rule groups and rate limits in practice
Most teams combine custom rules with managed rule sets from security vendors. Managed sets block common web exploits like SQL injection and cross-site scripting. Custom rules handle logic that is specific to your own app and users. For example, you might block traffic from regions where you do no business. You can also add rate-based rules to stop brute-force login attempts. A rate rule counts how many requests come from one IP address. If an IP sends too many requests in five minutes, the rule blocks it. Once the traffic drops below the limit, the rule lets that IP back in. Teams must watch rule order closely when they mix managed and custom rules. If a broad allow rule sits at the top, it skips later checks. Attackers can then slip past the managed rules lower down on the list.
What edge lists solve and what they miss
Edge rule lists do a great job of stopping automated internet noise. They drop bad packets early and keep public web servers up and running. Still, these lists only check web traffic coming from the outside world. They decide which HTTP requests cross the border into your network. They do not govern what engineers or internal services do inside your backend. Once a developer logs in to a database or server, edge rules cannot help. A web rule list cannot inspect live SQL queries or shell commands in flight. It cannot mask sensitive data like emails, phone numbers, or card numbers in results. Relying only on perimeter rules leaves internal data and admin sessions wide open. Teams need deeper controls that check every single query and command at runtime.
Web-Based Terminal Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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 a network ACL and a web ACL?
A network list filters traffic at the IP and port level for subnets. A web list inspects HTTP content like headers, paths, and body payloads for apps.
How should we test new rules before blocking real traffic?
Set the new rule to count mode first and watch your traffic logs. Once you confirm no real users match the rule, switch it to block.
Does a web ACL protect against internal database misuse?
No, it only filters external HTTP requests at the edge of your network. It does not check direct database sessions or mask private fields in query results.