Identory Proxy
You set up an identory proxy by adding a remote host and port to a browser profile. This routes traffic from that isolated profile through a single IP address. Engineering and testing teams often use these profiles to test regional apps or manage multiple vendor accounts. Still, sharing profiles with saved keys and broad roles creates major security risks. How an identory proxy workflow operates An anti-detect browser builds a separate space for each user profile on a machine. Each profile ho
Database Proxy (ProxySQL, PgBouncer): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an identory proxy by adding a remote host and port to a browser profile. This routes traffic from that isolated profile through a single IP address. Engineering and testing teams often use these profiles to test regional apps or manage multiple vendor accounts. Still, sharing profiles with saved keys and broad roles creates major security risks.
How an identory proxy workflow operates
An anti-detect browser builds a separate space for each user profile on a machine. Each profile holds its own cookies, local storage, and hardware fingerprint settings. When you attach an identory proxy to a profile, the browser sends that profile's web traffic to your chosen remote server. The remote server then forwards the requests to the destination web app.
Teams use this setup to keep cookies and login states apart across many accounts. A tester can check how a web app loads from five different regions at once. Each window looks like a unique device with its own network path. Team leads can also sync these profiles across multiple staff computers. When one person logs into a cloud dashboard, the session cookie saves to the shared profile. The next team member opens that profile and skips the login prompt.
To make this work, an admin adds the network host, port, and login details into the profile settings. The browser checks the network path before opening the window. Once the check passes, the user works inside that browser tab as normal.
What profile routing solves and what it leaves open
This browser setup solves account overlap and regional testing blocks. It keeps session cookies clean and stops websites from linking test accounts together. It also gives teams a quick way to share web sessions without texting passwords back and forth.
Still, routing a browser profile does not secure internal databases, cloud consoles, or servers. First, shared browser profiles hide who actually ran an action. If five engineers share one profile to manage a cloud console, the cloud log shows one account. You cannot tell which person deleted a table or changed a security rule. Second, the profile stores raw session tokens and static proxy keys on local machines. If an attacker steals the profile data, they gain full entry to every logged-in app.
Database Proxy (ProxySQL, PgBouncer): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Most of all, a browser network rule only controls where the traffic exits. It decides how a user connects, not what their actions do in flight. Once a user opens an admin dashboard or web tool, they hold the full power of that role. The browser cannot stop a dangerous query or block a bulk data export. It also cannot mask sensitive fields like emails, phone numbers, card numbers, or national IDs on the screen.
Managing shared browser profiles in a team
If your team uses profile tools for testing, keep them away from production systems. Never save production cloud keys or database admin sessions inside a shared browser profile. Use dedicated test accounts that hold no real customer records.
You should also clear cookies and local storage after every test run. Set strict role limits inside the profile management app so staff only open the profiles they need. Rotate the network keys on a regular schedule to limit the damage from leaked files. For real production systems and internal tools, move away from shared browser states and enforce checks on every single command or query.
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 does an identory proxy setting do?
It routes the web traffic of one isolated browser profile through a specific IP address. This lets a user run multiple browser windows that each show a different network location.
Is a browser profile router safe for production admin work?
No, sharing logged-in browser profiles erases individual audit trails and stores active session cookies on user disks. Teams should use individual logins and command-level controls for production tasks.
How do teams audit actions inside shared browser profiles?
The browser tool itself only logs who opened the profile and when. It does not record which clicks, API calls, or database queries the user ran inside the web session.