Airgap Js
You set up airgap js by loading a client script before other tags run. This script blocks network requests that lack user consent or match a block list. Engineering teams add this tool to stop third-party scripts from leaking user data. When browser rules are too broad, hidden scripts still send data to outside servers. A missed rule lets trackers read page state and send it away. How an airgap js setup works in the browser The script runs at the very top of your web page header. It wraps sta
Js: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up airgap js by loading a client script before other tags run. This script blocks network requests that lack user consent or match a block list. Engineering teams add this tool to stop third-party scripts from leaking user data. When browser rules are too broad, hidden scripts still send data to outside servers. A missed rule lets trackers read page state and send it away.
How an airgap js setup works in the browser
The script runs at the very top of your web page header. It wraps standard browser network tools like fetch and XMLHttpRequest right away. It also watches document nodes that add new scripts, pixels, or frames. When a script tries to send data out, the wrapper stops the call. It checks the destination domain against a local list of allowed endpoints.
It also checks what consent choices the user made in their browser session. If the domain lacks approval, the script drops or queues the request locally. Teams manage these domain rules inside a central dashboard and push updates out. The browser pulls the rule file and applies it to every single page view. This workflow stops rogue tags from talking to outside marketing or analytics servers.
What native browser rules solve and what they miss
Browser script rules do a great job of blocking third-party trackers on pages. They help privacy teams enforce user consent choices for outside marketing scripts. They also give front-end teams a clear view of which domains scripts call. Still, browser controls only govern traffic that leaves the client web page itself. They cannot protect the internal databases or servers that feed your web app.
Also, a clever script can run before the wrapper loads and bypass checks. Once traffic hits your own backend API, client-side script rules no longer apply. Standard role checks only decide who can log in to those backend systems. They do not inspect what individual queries or commands do while in flight. An engineer or backend service with broad database rights can still pull raw rows. Native client scripts cannot rewrite sensitive fields like emails or card numbers in databases. Teams still need server controls to watch queries and mask data in results.
Js: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Steps to keep client and server rules aligned
First, list every outside domain that your web app calls during normal use. Group each domain by its clear purpose, such as core app logic or analytics. Set your default browser rule to block any domain not on this list. Test your web app in a staging setup to catch broken page features.
Watch the blocked request logs to find stray scripts added by other teams. Next, look at the backend services that handle requests from your approved domains. Make sure those services and your team members use narrow database roles. Add query checks on the server side so sensitive fields get masked in results. Masking rewrites matched fields like phone numbers or national IDs before queries return.
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 airgap js control in a web app?
It controls outbound network calls made by scripts running inside the user browser. It checks each request against domain rules and user consent before data leaves.
Can users or scripts bypass client-side network blocks?
Yes, anyone with browser dev tools can alter client scripts or page rules. Also, any script that loads before the main wrapper can send data out.
Does a browser script blocker protect backend databases?
No, browser tools only watch traffic inside the client web page itself. You need separate server controls to check database queries and mask returned fields.