Why do JSON-RPC services create blind spots for traditional API security testing?

Why This Matters for Security Teams

JSON-RPC changes the way attack surface is exposed. Instead of distinct resource paths that security scanners can enumerate, many actions are compressed into a single endpoint with methods, parameters, and state changes hidden in the request body. That means traditional discovery, crawling, and route-based testing can give a false sense of coverage. This is especially risky when security controls assume the URL is the unit of protection rather than the method and its authorization context.

For security teams, the practical issue is not simply whether the endpoint is reachable, but whether each callable method enforces the correct identity, privilege, and input validation rules. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on identifying assets, protecting access, and validating security assumptions across the environment. JSON-RPC also complicates logging and detection because method names may not appear in standard web telemetry unless request bodies are parsed and correlated. In practice, many security teams encounter these blind spots only after a low-visibility method has already been abused rather than through intentional API inventory and method-level review.

How It Works in Practice

JSON-RPC services typically expose one endpoint that accepts structured calls such as a method name, parameters, and an identifier. The service then dispatches the request internally to the relevant function. That design is efficient for application developers, but it breaks assumptions used by many web security tools. A scanner that looks for paths like OWASP API Security Top 10 style resource enumeration can identify the endpoint, yet still miss the full set of callable methods and the specific business logic behind them.

In practice, effective testing needs to shift from surface enumeration to message and schema inspection. That usually means:

• Building an authoritative method inventory from code, documentation, or server-side introspection where permitted.
• Testing each method for authentication and authorization consistency, especially where one endpoint serves multiple roles.
• Validating parameter handling, including unexpected object shapes, nested values, and type confusion.
• Checking whether error messages, timing, or response structure reveal hidden methods or privilege differences.
• Confirming that logs preserve method names and relevant context for incident response and SIEM correlation.

Security teams should also map this testing to control expectations in the CISA Secure Software Development Framework, because the biggest failures often originate in design choices rather than perimeter gaps. JSON-RPC is not inherently insecure, but it requires the application to treat the method as the true security boundary and to enforce authorization at that layer, not just at the transport or endpoint layer. These controls tend to break down when multiple internal services reuse the same gateway and rely on inconsistent method naming, because testers cannot reliably infer which actions exist or which identity checks apply.

Common Variations and Edge Cases

Tighter method-level control often increases implementation and testing overhead, requiring organisations to balance hidden attack-surface reduction against developer convenience and release speed. That tradeoff becomes more pronounced in microservice environments, where JSON-RPC may be wrapped by gateways, service meshes, or shared authentication layers that obscure where authorization is actually enforced.

There is no universal standard for method discovery in JSON-RPC, so current guidance suggests combining static code review, contract testing, and runtime observability rather than relying on a single scanner. Batch requests are a common edge case because they can combine high-volume or mixed-privilege operations into one call, which can confuse rate limiting and make abuse harder to separate from legitimate client behaviour. Another common gap appears when teams instrument only HTTP status codes and miss application-level failures that are encoded inside a successful transport response.

This is also where identity considerations matter. If a service accepts machine-to-machine access, the real question is whether credentials, tokens, and service identities are authorised for each callable method. That intersects naturally with non-human identity governance, because a shared service account or overbroad token can expose multiple methods behind one endpoint even when the URL surface looks small. Good testing therefore checks both the RPC contract and the identity context behind it, not just the endpoint itself. The OWASP API Security Top 10 is useful here as a baseline, but JSON-RPC needs deeper method-aware validation than path-centric API assessments.

Related resources from NHI Mgmt Group

• Why do API-first applications create blind spots for security teams?
• Why do APIs create more runtime testing blind spots than traditional web apps?
• Why do CSV and JSON files create security blind spots?
• Why do fixed testing windows create blind spots in modern security programmes?