Signando REST
The Application Layer Gateway that takes API security to the extreme. Every request and response is validated against your OpenAPI specification.
What is Signando REST?
Signando REST is an Application Layer Gateway (ALG) that sits between your clients and your backend APIs. It validates every single HTTP request against your OpenAPI 3.0 specification before forwarding it to your backend.
But we don't stop there. Signando REST also validates every response from your backend before sending it to the client. This bidirectional validation ensures:
- Malicious requests never reach your backend
- Sensitive data cannot leak through unexpected response fields
- Your API contract is enforced in both directions
Technical Specifications
| Language | 100% Rust |
| Latency | < 250ms |
| Security Tests | 181 Tests |
| Architecture | 4 isolated NATS instances |
| OpenAPI | 3.0 / 3.1 Support |
| Deployment | Docker / Kubernetes |
The Paranoid Approach
Allowlist Instead of Blocklist
Unlike traditional WAFs that try to block known malicious patterns, Signando REST only allows what is explicitly defined in your OpenAPI specification. Everything else is rejected.
4-Stage Isolation
Four separate NATS JetStream instances ensure that data from different processing stages cannot leak between components, even if one is compromised.
Bidirectional Validation
Both requests and responses are validated. This prevents data exfiltration and ensures your backend never sends unexpected data to clients.
The 4 Processes in Detail
Each process is isolated and communicates exclusively through defined channels.
1. Frontend
The only process with direct client contact. Receives HTTP requests and forwards them for validation.
Input
- HTTP requests from clients on Port 8080
- Supports: GET, POST, PUT, DELETE, PATCH
- TLS termination (optional)
Output
- Writes request data to NATS 1 (Dirty Queue)
- Writes entries to AuditLog
- Reads validated responses from NATS 4 (Clean Queue)
- Sends HTTP response to client
🔒 Security Rules
- No direct connection to backend server
- Can only access NATS 1 (write) and NATS 4 (read)
- Request body is not interpreted, only forwarded
- Timeout handling for unanswered requests
- Rate limiting by IP possible
- Stateless: Can be horizontally scaled (multiple instances, e.g. behind a load balancer)
2. Request Validator
Validates incoming requests against the OpenAPI specification. Only valid requests are forwarded.
Input
- Reads request data from NATS 1 (Dirty Queue)
- Loads OpenAPI specification (YAML/JSON)
Output
- Writes validated requests to NATS 2 (Clean Queue)
- Writes validation result to AuditLog
🔒 Security Rules
- No HTTP server: Opens no ports, only polls the NATS queue
- No network connection except NATS 1 (read) and NATS 2 (write)
- Strict OpenAPI validation: path, method, headers, query parameters, body
- Allowlist principle: Only explicitly defined endpoints allowed
- Type validation: String, Integer, Boolean, Array, Object
- Pattern validation: Regex for strings (e.g. email, UUID)
- Enum validation: Only allowed values
- Injection detection: SQL, XSS, Command Injection patterns
- Stateless: Can be horizontally scaled (multiple instances)
3. Backend
Forwards validated requests to the actual backend server and receives its responses.
Input
- Reads validated requests from NATS 2 (Clean Queue)
Output
- Calls backend server on Port 8080 (configurable)
- Writes backend response to NATS 3 (Dirty Queue)
- Writes call details to AuditLog
🔒 Security Rules
- No direct connection to client (only via NATS)
- Can only access NATS 2 (read) and NATS 3 (write)
- Backend connection only to configured host/port
- Timeout handling for slow backend responses
- Retry logic for temporary errors (configurable)
- Circuit breaker for backend failures
- Stateless: Can be horizontally scaled (multiple instances)
4. Response Validator
Validates backend responses against the OpenAPI specification. Prevents data exfiltration and unexpected response structures.
Input
- Reads backend responses from NATS 3 (Dirty Queue)
- Loads OpenAPI specification (YAML/JSON)
Output
- Writes validated responses to NATS 4 (Clean Queue)
- Writes validation result to AuditLog
- On error: Generates safe error response
🔒 Security Rules
- No HTTP server: Opens no ports, only polls the NATS queue
- No network connection except NATS 3 (read) and NATS 4 (write)
- Response schema validation: Only defined fields are passed through
- Prevents data exfiltration through unexpected response fields
- Content-Type validation: Only allowed formats (e.g. application/json)
- Status code validation: Only codes defined in OpenAPI
- Header filtering: Only allowed response headers
- Stateless: Can be horizontally scaled (multiple instances)
Data Flow Overview
┌──────────────────────────────────────────────────────────────────────────────┐ │ │ │ Client ──▶ Frontend ──▶ NATS 1 ──▶ Request ──▶ NATS 2 ──▶ Backend │ │ │ (8080) (Dirty) Validator (Clean) │ │ │ │ │ │ │ │ ▼ │ │ │ Backend Server │ │ │ (8080) │ │ │ │ │ │ │ ┌───────────────────────────────────────────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ NATS 3 ──▶ Response ──▶ NATS 4 │ │ │ (Dirty) Validator (Clean) │ │ │ │ │ │ │ ▼ │ │ ◀───────────────────────────── Frontend │ │ │ │ ════════════════════════════════════════════════════════════════════════ │ │ Each process also writes to the AuditLog │ └──────────────────────────────────────────────────────────────────────────────┘
Ready to Protect Your APIs?
Contact us for a demo and personal consultation.