The /json endpoint is an HTTP discovery endpoint used by Chrome’s remote debugging interface to list available debug targets and protocol metadata. Clients query it to find page, worker or browser targets and the WebSocket debugger URLs needed to attach to them.
What the /json endpoint does
The /json endpoint is part of Chrome’s remote debugging interface, so its core job is discovery. It returns the current set of debuggable targets and the metadata a client needs to connect, including the WebSocket debugger URL for each target. In practice, it is the starting point for tooling that attaches to a browser, tab, worker or similar runtime target.
Because it exposes live target inventory and connection details, the endpoint is less about content and more about control-plane visibility. It helps automation decide what is available to inspect, but it also reveals which debugging surface is currently open and reachable.
How discovery and attachment work
Clients usually query /json first, then choose a target from the returned list and use the associated WebSocket URL to attach. That separation matters: discovery is HTTP-based, while active debugging happens over the debugger transport. This design lets scripts and tooling enumerate targets before opening a persistent debugging session.
The metadata returned by the endpoint typically includes enough information to distinguish pages, workers and the browser process itself. That is useful for automation, but it also means the endpoint can be used to map the browser’s live attack surface if remote debugging is exposed beyond a local trust boundary.
Why the endpoint matters in security tooling
The /json endpoint is often used legitimately by browser automation, QA harnesses and developer tooling because it provides a machine-readable way to find the right target. In security terms, it is a discovery interface for a privileged control channel, so access to it should be treated as sensitive even if it is only intended for local use.
Its value comes from its simplicity: once a client knows the debugger WebSocket URL, it can interact with a target directly. That makes the endpoint operationally useful, but it also means exposure, logging, and process isolation around the remote debugging interface deserve attention whenever the browser runs in shared, containerised or remotely accessible environments.
Common misuse patterns and defensive boundaries
When remote debugging is enabled and reachable, /json can become an easy recon point for anyone who can contact the port. A caller does not need a browser UI, only network access to enumerate targets and learn how to connect. That is why this endpoint should be assumed sensitive on developer machines, CI hosts, test rigs and automation nodes.
Defensive boundaries should focus on where the debugging interface listens, who can reach it, and whether that exposure is intentional. If the interface is meant for local automation only, network controls and host-level restrictions are part of the security model, not optional hardening.
Risk and Threat Considerations
The main risk is that a discovery endpoint can turn an internal debugging feature into an externally reachable control surface. If attackers or unauthorized users can query /json, they may learn what targets exist and obtain debugger connection details that lead to deeper browser compromise, session abuse, or inspection of in-memory application state.
Failure mechanism: Exposure of the remote debugging listener allows unauthenticated or low-friction enumeration of targets, followed by attachment to the debugger transport if the port is reachable.
Impact: This can expose live browser sessions, sensitive page state, authenticated application interactions, and any trust placed in the debugging channel.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The endpoint is part of an exposed API-style debug surface whose reachability and access controls are security-sensitive. |
| Recommendation — Restrict debug port exposure and validate configuration so the /json discovery endpoint is not reachable beyond trusted use. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Remote debugging discovery depends on controlling who can reach the listener and use returned debugger URLs. |
| IA-5 — Authenticator Management | If debugger access is protected by credentials or tokens, their lifecycle governs who can attach after discovery. | |
| Recommendation — Enforce network and host-level access controls around the debugging listener so only approved clients can query /json. Manage any debugger credentials or tokens so only intended operators can convert discovery into a live attach session. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | The endpoint exposes a control path that depends on limiting access to trusted operators and tools. |
| Recommendation — Limit access to the debugging interface and verify that only approved automation can use the discovery endpoint. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Remote debugging listeners are configuration-sensitive and should not be broadly exposed by default. |
| Recommendation — Harden browser and host configuration so remote debugging is enabled only where it is required and controlled. | ||
Practitioner Guidance
Why practitioners should care: Treat /json as a discovery surface that should only be reachable by trusted automation and local tooling. If the debugging interface is reachable outside its intended boundary, the endpoint can reveal enough metadata to make unauthorized attachment much easier.
What to watch for: Any process that exposes the remote debugging port on a shared host, container, build agent or remote workstation should be reviewed carefully. If that exposure is intentional, make sure the surrounding network and host controls match the sensitivity of the browser session being debugged.
Related resources from NHI Mgmt Group
- What is the difference between endpoint compromise and management-plane compromise?
- What is the difference between endpoint malware detection and workload identity governance?
- What is the difference between endpoint containment and identity containment?
- How should teams extend Zero Trust to endpoint devices?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org