Zscaler Web Proxy
You set up a zscaler web proxy by forwarding device traffic to its cloud nodes. Then you link your identity provider and write URL filtering rules for user groups. Many teams start by giving whole departments broad web access to avoid blocking daily work. When permissions are too wide, engineers can reach sensitive internal apps without strict checks. A single stolen laptop session can then expose private dashboards and internal APIs. How a zscaler web proxy routes and checks traffic The syst
Database Proxy (ProxySQL, PgBouncer) + JSON Web Tokens (JWT): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a zscaler web proxy by forwarding device traffic to its cloud nodes. Then you link your identity provider and write URL filtering rules for user groups. Many teams start by giving whole departments broad web access to avoid blocking daily work. When permissions are too wide, engineers can reach sensitive internal apps without strict checks. A single stolen laptop session can then expose private dashboards and internal APIs.
How a zscaler web proxy routes and checks traffic
The system sits between user devices and the public web or private web apps. You install a lightweight agent on each laptop or set up network tunnel forwarding. When a user opens a site, the agent sends that request to the nearest edge node. The cloud service checks who the user is through your single sign-on provider.
Next, the service reads the group roles tied to that user profile. It compares the target URL against your company allow and block rules. To inspect encrypted web traffic, you must install a root certificate on user machines. The service then decrypts the web request, scans for threats, and sends it onward.
For developer tools, you must often bypass certificate inspection on specific domains. Many command line tools and package managers reject custom root certificates by default. Teams maintain long bypass lists so developer builds and scripts do not break. Each bypass rule reduces visibility into what leaves or enters the developer machine.
What network web filtering solves and what it misses
A cloud web filter is great at stopping users from visiting known bad domains. It blocks malware downloads and keeps staff off risky sites on company laptops. It also replaces legacy VPN hardware for basic browser access to internal web portals. Network teams get a central log of which user visited which host name.
Still, a network filter only decides who can open a web site or app. It does not understand the actual commands or database queries sent inside an approved session. Once an engineer logs into an internal admin tool, the web filter steps back. It cannot tell a safe read action from a destructive delete action.
Database Proxy (ProxySQL, PgBouncer) + JSON Web Tokens (JWT): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, engineers do not only work inside standard web browsers. They run terminal sessions, query production databases, and connect to cloud clusters directly. Web filters do not inspect raw database protocols or command line traffic well. If you rely only on web rules, your backend data keeps the session active to broad roles. Sensitive data like emails, phone numbers, and card numbers can return in full view. You need a way to check individual commands and mask data in flight.
Best practices for managing developer web rules
Start by separating general office browsing from engineering access to production systems. Group your users by clear job functions rather than broad department names. Keep your certificate bypass list as short as possible and review it every month. When a developer tool fails, check which specific host needs an exception before opening whole domains.
Pair your web filter with tight controls at the database and server level. Do not trust network location or a passed web check as full proof of authorization. Every sensitive action inside an internal system should require its own review and log entry.
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
Why do developer command line tools fail behind a web filter?
The filter swaps website certificates with its own root certificate to scan traffic. Developer tools use strict certificate stores and reject unknown root certificates right away. You must add the custom root certificate to each tool or bypass those domains.
Does a web filter protect internal databases and servers?
No, a web filter focuses on HTTP and HTTPS traffic from browsers and web apps. It does not parse raw database queries or terminal commands sent over other ports. You need dedicated controls that understand database and server protocols to secure those systems.
How can we stop sensitive data from leaking through internal web tools?
Web filters can block file uploads, but they rarely parse live database responses well. To protect emails, phone numbers, or national IDs, apply data masking at the data layer. Masking rewrites matched fields in query results before the app or user gets them.