Network-based Waf
You set up a network based waf by placing hardware appliances in front of your web servers. This appliance reads HTTP packets and blocks bad web requests before they reach your app. Security teams place these boxes at the edge of the local network to stop web attacks. They write rules to catch bad payloads like SQL injection and cross-site scripting. Still, edge web filters do not inspect direct database sessions or internal engineer commands. When internal roles have broad rights, one bad query
AWS WAF: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a network based waf by placing hardware appliances in front of your web servers. This appliance reads HTTP packets and blocks bad web requests before they reach your app. Security teams place these boxes at the edge of the local network to stop web attacks. They write rules to catch bad payloads like SQL injection and cross-site scripting. Still, edge web filters do not inspect direct database sessions or internal engineer commands. When internal roles have broad rights, one bad query can still drop tables or leak data.
How a network based waf inspects web traffic
A network based waf sits directly in your local network path, close to your servers. Teams install it as a physical appliance or a virtual machine inside their data center. Because it sits right next to the target servers, it adds very little delay. Every incoming web request must pass through this box before the web app sees it.
To read safe web traffic, the appliance needs your private TLS keys. It decrypts the incoming packet, reads the HTTP headers and body, and runs rule checks. Teams use vendor rule sets to spot known attack patterns in forms and URLs. They also write custom rules to block strange traffic shapes or high request rates.
If the request matches a block rule, the appliance drops the packet right away. If the packet looks clean, the box sends it on to the web server. Teams can also run the box in an alert mode first. This mode logs matches without dropping packets so engineers can fix false alarms.
What edge filtering solves and what it misses
This edge setup is great at stopping public web attacks at high speed. It shields public web apps from bots, scanners, and common input bugs. Because it runs on dedicated hardware, it handles huge traffic spikes without blocking the app. It gives network teams one central place to manage web rules for local servers.
Yet this setup only sees public web traffic that comes through the front door. It does not check what engineers or services do once they log in internally. Engineers do not use public web forms to run maintenance tasks on databases or servers. They use command line tools, database clients, and direct internal network paths.
AWS WAF: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
An edge web filter cannot read native database protocols or SSH sessions. Once a user logs in to a database, the edge box cannot see their queries. If an engineer has a broad role, they can read raw emails or card numbers. They can also run a bad update statement that breaks production tables.
Why internal sessions need command and query controls
Relying only on edge web boxes leaves a huge blind spot inside your network. Internal users and scripts bypass the web tier and talk straight to data stores. Shared admin accounts make this worse because logs cannot tie actions to one person. Teams need a way to check every command and query in flight.
Instead of checking only public web packets, teams must control internal sessions at the protocol level. Every query should link back to an individual identity from your directory. Read queries that return sensitive fields like phone numbers or national IDs need field masking. Masking rewrites matched fields in results before the client tool displays them. High-risk commands should pause for peer review before they run on production systems.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does a network based waf differ from a host-based filter?
A network unit runs on separate hardware in the network path for many servers. A host-based filter runs as software inside one app server and uses that server's CPU.
Why do false positives happen on web filters?
Generic rules look for text patterns that resemble code or database commands. Normal user input sometimes matches those patterns, which causes the filter to block valid requests.
Does a web filter protect internal database sessions?
No, it only inspects HTTP and HTTPS traffic aimed at web apps. Direct database sessions from engineers or internal scripts bypass the web filter completely.