REST oriented scanning usually discovers resources by crawling many URLs, while JSON-RPC testing starts with the method schema and tests a single endpoint. That difference matters because JSON-RPC attack surface sits in method names, params, and authorization rules. Schema driven testing gives scanners enough context to fuzz inputs and validate behaviour accurately.
Why This Matters for Security Teams
REST oriented scanning and JSON-RPC schema driven testing expose different failure modes, so treating them as equivalent leaves blind spots in assessment coverage. REST tools are strongest when the application advertises many resources and verbs across discoverable paths. JSON-RPC, by contrast, often compresses the attack surface into one endpoint where method names, parameter objects, and authorization logic do most of the work. The practical risk is not just missed bugs, but missed trust boundaries between public methods, internal methods, and privileged operations. That is why control thinking from the NIST Cybersecurity Framework 2.0 matters here: asset visibility and control validation have to match the interface style, not the assessment habit.
Security teams often assume a scanner that finds issues in REST will automatically handle JSON-RPC, but JSON-RPC typically needs schema awareness to understand which methods exist, which parameters are optional, and which responses indicate failure versus business logic. Without that context, scanners may report noise, miss privilege escalation paths, or fail to exercise sensitive method combinations. In practice, many security teams encounter these gaps only after an exposed method has already been abused, rather than through intentional test design.
How It Works in Practice
REST oriented API scanning usually begins by enumerating paths, observing HTTP verbs, and probing responses to identify hidden endpoints, weak input handling, and broken object-level authorization. It benefits from breadth because the attack surface is spread across many URLs and resources. JSON-RPC schema driven testing works differently. The scanner starts with the method catalogue, OpenAPI-like descriptions, or hand-curated schema to understand the request structure, then tests the single JSON-RPC endpoint for method dispatch, parameter validation, and authz enforcement.
In operational terms, the tester should look for these JSON-RPC characteristics:
- Method discovery from schema, code comments, docs, or traffic capture rather than URL crawling.
- Parameter fuzzing that respects types, nesting, required fields, and edge values.
- Authentication and authorization checks per method, especially where one endpoint exposes public and privileged actions.
- Response validation for business logic errors, partial failures, and inconsistent error objects.
This is where schema quality becomes a security control. Good schema driven testing depends on accurate method names, stable parameter definitions, and up-to-date authorization mappings. When those inputs are missing, testers should supplement the scan with manual exploration and traffic replay. Guidance from OWASP API Security Top 10 remains useful for both styles of testing because broken object authorization, excessive data exposure, and mass assignment still appear regardless of protocol. For JSON-RPC specifically, testers should also verify that method routing does not permit unintended aliases or reflection of internal handlers, and that batch requests do not bypass per-call controls. These controls tend to break down when the API gateway normalises requests incorrectly or when a shared endpoint maps multiple privilege levels into one dispatcher because the scanner sees only one surface while the backend enforces many hidden rules.
Common Variations and Edge Cases
Tighter schema driven testing often increases setup overhead, requiring organisations to balance deeper method coverage against the cost of maintaining accurate definitions. That tradeoff is real, especially in fast-moving environments where schemas drift faster than test baselines.
Best practice is evolving for mixed estates. Some teams expose REST and JSON-RPC side by side, and the same application may require both crawling and schema-led tests. In those cases, the right approach is not either-or. REST discovery handles the resource layer, while JSON-RPC tests validate the method layer. If the interface is generated dynamically, or if the schema is incomplete, current guidance suggests combining passive traffic observation, authenticated replay, and manual review instead of trusting automated coverage alone.
There is also an identity and privilege angle. JSON-RPC methods often map directly to actions such as admin lookups, token minting, or account changes, so access control review should verify that method-level authorization is enforced independently of session presence. REST may rely more visibly on object IDs and path controls, while JSON-RPC often hides control decisions inside dispatcher logic. For broader attack modelling and control mapping, the OWASP API Security Top 10 and the operational resilience lens of the NIST Cybersecurity Framework 2.0 remain the most practical references.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Interface inventory must distinguish REST routes from JSON-RPC methods. |
Inventory API surfaces by protocol so scanners test the right attack paths.
Related resources from NHI Mgmt Group
- What is the difference between API security scanning and penetration testing?
- What is the difference between functional API testing and identity-focused onboarding testing?
- What is the difference between API testing and runtime API security?
- What is the difference between developer-native security testing and separate-console scanning?
