Kobaru
  1. Transparent Proxy
Kobaru
  • Kobaru.io Gateway API
    • Introduction
      • What is Kobaru?
      • Quick start
      • How x402 works
    • Integration
      • Standard x402 SDK
      • Advanced SDK
      • Transparent proxy integration
      • Direct API integration
    • Core Concepts
      • Available Chains and Assets
      • Payment schemes
      • Security
      • Usage models
    • Guides
      • Pricing your API
      • Going to Production
      • Testing with devnet
      • Bazaar discovery
    • API Reference
      • Error Handling
      • Get Supported Payment Kinds
      • Verify Payment Authorization
      • Settle Payment
    • Discovery
      • List Discovery Resources
    • Transparent Proxy
      • Overview - Transparent Proxy
      • Upstream authentication
      • Troubleshooting
      • Constraints and security
      • Capabilities and routes
      • Domain verification
      • Service setup
    • Schemas
      • SupportedResponse
      • ErrorResponse
      • UnauthorizedResponse
      • RateLimitResponse
      • VerifySuccessResponse
      • VerifyErrorResponse
      • SettleSuccessResponse
      • SettleErrorResponse
      • DiscoveryResourceItem
      • ListDiscoveryResourcesResponse
  1. Transparent Proxy

Constraints and security

The proxy enforces several constraints to protect your backend and prevent abuse. This page covers what's blocked, why, and how to work within these limits.

HTTPS requirement#

Your backend URL must use HTTPS. The system rejects HTTP URLs at both the database and application level.
https://api.example.com - Allowed
http://api.example.com - Rejected
For local development, use an HTTPS tunnel:
This gives you a public HTTPS URL that forwards to your local server.

Security restrictions#

The proxy enforces security restrictions to protect both your backend and our infrastructure. These restrictions ensure your proxy service operates securely and reliably.

Request limits#

ConstraintLimit
Request body size64KB maximum
Upstream timeout50 seconds
ProtocolHTTP/HTTPS only (no WebSocket)
If your use case requires larger request bodies or WebSocket support, use the Standard SDK instead.

Redirect blocking#

The proxy blocks all 3xx redirects from your backend for security reasons. If your backend returns a redirect, the proxy returns a 502 error to the client.
If your backend uses redirects internally, resolve them before they reach the proxy endpoint.

Domain verification#

Domain verification provides an additional layer of SSRF protection:
You can only proxy domains you've verified ownership of
Verifying example.com allows api.example.com and all subdomains
Each service's base URL is validated against your verified domains

Payment security#

Server-side requirements#

The proxy always determines payment requirements (amount, asset, recipient wallet) server-side from your configuration in the database. It never trusts client-provided values.
This means clients cannot:
Manipulate the payment amount
Redirect payments to a different wallet
Change the usage model or limits

Header sanitization#

Before forwarding requests to your backend, the proxy removes payment-related headers and optionally injects your upstream authentication key.
Your backend receives clean requests with no payment tokens or signatures.

Data isolation#

All proxy configuration is scoped to your account:
Domains - Only you see your verified domains
Services - Only you see your services
Capabilities - Only you see your enabled capabilities
Routes - Only you see your route overrides
No other merchant can access or modify your configuration.

Audit logging#

All proxy configuration changes are logged for security and compliance purposes.

Next steps#

If you run into issues, check the troubleshooting guide. For general security best practices, see the security concepts page.
Modified at 2026-02-10 21:51:40
Previous
Troubleshooting
Next
Capabilities and routes
Built with