Security teams should treat JSON-RPC as a distinct API surface and scan it with schema aware DAST. Because JSON-RPC often uses a single endpoint, traditional crawlers miss method level risk. Provide an OpenRPC schema, configure authentication, and run scans in the same pipeline as other API tests so injection, authorization, and exposure issues are found before release.
Why This Matters for Security Teams
JSON-RPC APIs can look deceptively simple because many methods share one endpoint, but that simplicity creates blind spots in release pipelines. Manual review alone rarely proves that authentication, authorization, parameter handling, and error behaviour are consistent across every method. Security teams need test coverage that treats the API contract, not the URL, as the unit of analysis. That is especially important when JSON-RPC backends expose admin functions, internal workflows, or automation hooks that are reachable from CI/CD.
For practitioners, the main risk is not only injection. It is method-level exposure where one function is protected and another is effectively open, especially when tooling assumes REST-style discovery. Current guidance from the NIST Cybersecurity Framework 2.0 aligns well with this problem because it emphasises identifying assets, managing risk, and validating protective controls continuously rather than relying on a one-time sign-off. In practice, many security teams encounter JSON-RPC exposure only after an internal method is already reachable from production, rather than through intentional test design.
How It Works in Practice
The most reliable approach is to make JSON-RPC testing part of the same CI/CD controls that already handle build verification, dependency checks, and API security testing. The key is schema awareness. An OpenRPC document gives scanners the method names, expected parameters, authentication requirements, and response shapes needed to probe the API intelligently. Without that contract, a crawler will usually see only one endpoint and miss the attack surface inside the methods.
A practical pipeline usually includes:
- Publishing the OpenRPC schema alongside the service and versioning it with the code.
- Running schema-aware DAST against a deployed test environment with valid authentication context.
- Checking method-level authorisation by calling sensitive methods with low-privilege identities and tampered tokens.
- Testing malformed parameters, type confusion, and oversized payloads to catch parser and validation issues.
- Verifying that error responses do not leak stack traces, internal object names, or debugging details.
This is also where API governance matters. If the pipeline cannot differentiate between public methods and administrative methods, the scan results will be noisy or incomplete. The OWASP API Security Project is a useful reference point for common API failure patterns, and the same principles apply to JSON-RPC even when the transport and method model differ from REST. In mature environments, security teams also correlate DAST findings with SIEM telemetry so that blocked requests, auth failures, and unusual method access can be detected after deployment.
Where this guidance tends to break down is in environments that generate methods dynamically or gate access through opaque service meshes, because scanners cannot reliably enumerate the live method set or preserve the right identity context.
Common Variations and Edge Cases
Tighter schema enforcement often increases pipeline overhead, requiring organisations to balance stronger coverage against release speed and maintenance effort. That tradeoff becomes more visible when JSON-RPC services are shared by multiple internal teams or when the schema is generated from code that changes frequently. In those cases, the main question is not whether to test, but how to keep the schema and test harness aligned without creating a false sense of coverage.
There is no universal standard for how much method discovery a CI scanner should perform against JSON-RPC. Best practice is evolving, but current guidance suggests combining contract-based tests with targeted negative tests rather than relying on broad fuzzing alone. For higher-risk workflows, security teams should also verify that privileged methods require explicit approval paths and strong service identity controls, especially when machine-to-machine access is involved.
Edge cases also include batch calls, notifications that do not return responses, and hybrid APIs that expose JSON-RPC alongside REST or gRPC. Those designs can confuse test baselines if the pipeline assumes a single interaction pattern. The OWASP REST Security Cheat Sheet is not a JSON-RPC standard, but it is still useful for thinking about authentication, least privilege, and output handling across API surfaces. Teams should adapt the control logic to the protocol rather than forcing a REST-only scanner to do the job. The biggest failures usually appear when a shared testing template is reused across services with different method semantics and no one validates the gaps before release.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS-Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Schema-aware API testing protects data flows and validates security behaviour before release. |
| MITRE ATT&CK | T1190 | JSON-RPC endpoints can be probed for public-facing exploitation paths and input abuse. |
| CIS-Controls | 16 | Application software testing directly supports secure verification of API controls. |
Map JSON-RPC tests to PR.DS and verify data handling, exposure, and response protection in CI/CD.
