How do organisations reduce method enumeration and information leakage in JSON-RPC error handling?

Why This Matters for Security Teams

Method enumeration in JSON-RPC is not a cosmetic issue. Distinct error messages can reveal which functions exist, which ones are protected, and where validation differs. That information helps an attacker narrow their recon, tune brute-force attempts, and identify high-value workflows faster than a conventional scan would. OWASP guidance on API security consistently treats excessive error detail as an exposure problem, especially when it leaks authorization state or internal routing logic. See also OWASP API Security Top 10 for the broader pattern of metadata leakage through API behavior.

The operational risk is highest when JSON-RPC sits behind gateways, service meshes, or agent-facing interfaces where requests are automated and high-volume. In those environments, a small difference in timing, code, or message text can become a reliable oracle for endpoint discovery. Security teams often focus on input validation but overlook error uniformity, even though enumeration is frequently the first step before abuse of privileged methods, exposed admin functions, or downstream secret retrieval. In practice, many security teams encounter this only after attackers have already mapped the method surface through routine probe traffic, rather than through intentional testing.

How It Works in Practice

The core design principle is to separate internal diagnostics from public responses. The client should receive one generic pattern for unknown methods, denied access, malformed requests, and other rejected calls, while the server logs retain full detail for debugging, correlation, and incident response. That means the public response should avoid naming the missing method, stating that the caller is unauthorized for a specific action, or implying whether the target object exists at all.

A practical implementation usually combines several controls:

• Return a consistent JSON-RPC error code and message for method-not-found and access-denied cases.
• Keep rich context in server-side logs, including request ID, principal, tenant, and policy decision.
• Use rate limiting and anomaly detection to spot repeated probing against method names.
• Apply schema validation before dispatch so malformed requests fail in the same public pattern.
• Standardise timeout and response size as much as possible to reduce side-channel signals.

For teams building modern AI or automation interfaces, this matters even more because agentic clients may discover and retry methods at machine speed. The Anthropic report on the first AI-orchestrated cyber espionage campaign report is a reminder that automated abuse often exploits exactly these fast-feedback behaviors. The right pattern is to make the public interface boring and the private telemetry rich. Where JSON-RPC is fronting multiple back-end services, a shared error mapper should normalise responses before they reach the client, otherwise different services will reintroduce leakage through inconsistent wording or status handling. These controls tend to break down when legacy methods return framework-default exceptions directly, because the default stack trace or exception class leaks implementation detail.

Common Variations and Edge Cases

Tighter error suppression often increases debugging effort and support cost, requiring organisations to balance attacker resistance against operational clarity. Current guidance suggests that the public surface should be as uniform as possible, but there is no universal standard for how much context is acceptable in partner-only or internal environments. Teams sometimes allow more specificity on trusted networks, yet that approach should be treated carefully because trust boundaries shift quickly in hybrid and agent-driven architectures.

Edge cases usually appear in three places. First, batch requests can accidentally reveal which item failed if the response ordering or cardinality changes. Second, authZ failures in multi-tenant systems may leak tenant existence if the error text differs between “not found” and “forbidden.” Third, observability pipelines can become a secondary leak if logs are broadly accessible to developers, support staff, or external platforms. NIST guidance on access control and logging principles, including NIST SP 800-53 Rev. 5, supports the split between controlled diagnostics and limited public disclosure. For teams building agent-facing APIs, OWASP’s LLM Top 10 also reinforces the need to prevent tool and method discovery through error behavior. The safest pattern is to define one response contract, one logging contract, and one review process for any exception path that touches externally reachable JSON-RPC methods.

Related resources from NHI Mgmt Group

• How can organisations reduce secret leakage in ServiceNow at scale?
• How can organisations reduce developer AI data leakage without blocking adoption?
• How can organisations reduce leakage before AI responses are generated?
• Should organisations block all AI use to reduce leakage risk?