JSON-RPC vs XML-RPC at a Glance

The security decision is not 'JSON safe, XML unsafe.' Both can expose privileged methods, broken authorization, oversized payloads and resource-exhaustion risks.

How JSON-RPC 2.0 Works

A JSON-RPC request contains jsonrpc: "2.0", a method, optional params and an optional ID. If the ID is absent, it is a notification and the server must not send a response. Responses carry either result or error plus the ID.

Batch requests can contain multiple logical operations in one payload and may be processed concurrently. Limit batch size and aggregate execution cost.

How XML-RPC Works

XML-RPC sends HTTP POST requests with XML containing one methodCall, method name and parameters. Responses contain a methodResponse with a value or fault.

Never map arbitrary method names directly to reflection, filesystem paths or privileged internal functions. Maintain an explicit method registry and authorization model.

Serialization and Interoperability

JSON is generally more compact and native to modern web stacks. RFC 8259 calls out interoperability issues such as duplicate member names and number precision; reject out-of-contract JSON rather than relying on parser quirks.

XML supports rich tooling but a larger parser feature set. Legacy XML-RPC interoperability may justify its use, but new services should compare JSON-RPC, REST and gRPC based on identity, gateway, schema and observability needs—not serialization aesthetics alone.

Security Differences

Method Authorization Is the Main Boundary

RPC makes operations explicit: invoice.approve, user.reset or system.restart. Authentication is not permission. Authorize each method and object/tenant, validate state transitions and separate administrative procedures.

Related Ammune reading: API authorization vs authentication and OWASP BFLA.

Parser Hardening

For JSON, use a standards-compliant parser—never eval()—and limit body size, depth, arrays and batch size. Decide duplicate-key handling and reject values outside the method schema.

For XML-RPC, disable external entities/DTD processing unless explicitly required and safely designed. Apply entity-expansion/document-size limits and use maintained parsers.

Errors, Notifications and Observability

Avoid stack traces, paths or internal exception detail in JSON-RPC errors or XML-RPC faults. JSON-RPC notifications intentionally receive no response, so security-sensitive operations should not rely on notification semantics unless another acknowledgement/audit channel exists.

Log method, authenticated subject, authorization result, correlation ID and outcome without recording secrets or unnecessary sensitive parameters.

Which Should You Choose?

Gatewaying and Exposing RPC Safely

Many RPC services are safest when they are not directly internet-facing. An API gateway or application façade can terminate authentication, enforce request-size/rate limits and expose only a curated set of RPC methods. This is especially useful for legacy XML-RPC services whose native authentication and observability are limited.

Do not assume the gateway can replace method-level authorization. The gateway may know that a caller can reach /rpc, while only the service knows whether that caller may execute billing.refund for a specific tenant or object. Preserve authenticated identity securely across the gateway boundary and re-enforce authorization close to the operation.

For JSON-RPC batches, define whether gateway limits count the HTTP request or each contained RPC operation. A limit of 100 HTTP requests per minute can still permit thousands of method calls if each request contains a large batch.

Browser-Facing RPC: Cookies, CORS and CSRF

When RPC is called from a browser, transport and parser security are not enough. If authentication relies on ambient cookies, state-changing RPC methods can become CSRF targets unless the application enforces appropriate CSRF protections. CORS is a browser read-policy mechanism and should not be treated as a replacement for CSRF defense.

Prefer explicit authorization headers/tokens for API-style browser clients where the architecture permits, validate request origin/context where appropriate and use SameSite cookies as defense in depth. Do not assume application/json alone forms a complete CSRF boundary.

Legacy XML-RPC endpoints often use Basic authentication or application sessions. Placing internet-facing legacy RPC behind a gateway/facade can standardize authentication, rate limits and browser-origin policy.

JSON-RPC vs XML-RPC: Security Decision Matrix

For a new system, protocol choice should follow ecosystem and interoperability requirements. The decisive security controls—authentication, method/object authorization, schema validation, resource limits and observability—must exist either way.

RPC Security Checklist

• Use TLS.
• Authenticate clients/services.
• Allowlist methods.
• Enforce method/object authorization.
• Validate per-method parameters.
• Limit body/depth/batch/execution cost.
• Avoid eval/reflection dispatch.
• Disable unsafe XML entities/DTDs.
• Handle duplicate JSON fields consistently.
• Do not leak internal errors.
• Rate-limit expensive methods.
• Log identity, method and outcome.

Frequently Asked Questions

Primary References