Security Measures That Protect API Keys and Credentials in OmniRoute

OmniRoute implements a defense-in-depth strategy that extracts API keys only from secure header locations, validates them against an encrypted SQLite store, and redacts sensitive data from logs through opt-in guardrails.

OmniRoute is an open-source AI gateway that centralizes routing between clients and large language model providers. Understanding the security measures that protect API keys and credentials in OmniRoute is essential for production deployments handling sensitive authentication data. The codebase implements a comprehensive security perimeter spanning extraction, validation, storage, and runtime redaction to prevent credential leakage.

Secure API Key Extraction

The extractApiKey() function in src/sse/services/auth.ts (line 2437) implements a hierarchical extraction strategy that prioritizes security over convenience. It first checks for a standard Bearer token in the Authorization header, then falls back to provider-specific headers including x-api-key (only when the Anthropic-Version header is present) and x-goog-api-key.

For VS Code integration, the function supports path-scoped tokens embedded in URL paths, but explicitly rejects query string parameters to prevent accidental logging of keys in access logs or browser history. All header comparisons are case-insensitive, and extracted values are automatically trimmed of whitespace to prevent copy-paste errors from bypassing validation.

// Example: Path-scoped token extraction for VS Code integration
import { extractApiKey } from "@/sse/services/auth";

const request = new Request("http://localhost/api/v1/vscode/raw/abcd1234/..."); 
const token = extractApiKey(request, { allowUrl: true }); // returns "abcd1234"

Encrypted Storage and Strict Validation

Once extracted, keys undergo validation via isValidApiKey(), which queries the encrypted SQLite database defined in src/lib/db/apiKeys.ts. The encryption layer in src/lib/db/encryption.ts ensures that API keys are never written to disk in plaintext, protecting against file system breaches.

Validation is performed centrally for every protected route. For example, in src/sse/handlers/chat.ts (line 62), the handler validates the key before processing the request:

// Example: Extracting and validating an API key in a route handler
import { extractApiKey, isValidApiKey } from "@/sse/services/auth";

export async function handler(request: Request) {
  const apiKey = extractApiKey(request);
  if (!apiKey || !(await isValidApiKey(apiKey))) {
    return new Response("Invalid API key", { status: 401 });
  }
  // proceed with the protected operation …
}

Runtime Data Protection

OmniRoute includes guardrails that redact sensitive data from request and response bodies, but only when explicitly enabled. The PII_Masker guardrail consults the PII_REDACTION_ENABLED environment variable (defaulting to false) as implemented in src/lib/guardrails/piiMasker.ts (line 13). Similarly, the Credential_Masker mirrors this behavior via CREDENTIAL_REDACTION_ENABLED.

This opt-in design ensures that production deployments do not unintentionally expose internal data through logs or error traces. Guardrail registration occurs in src/server-init.ts and src/lib/guardrails/registry.ts (line 93), where each guardrail is activated only when its corresponding environment variable is set.

// Example: Enabling PII redaction via environment variable
process.env.PII_REDACTION_ENABLED = "true"; // opt‑in

// Inside a guardrail (src/lib/guardrails/piiMasker.ts)
export function shouldMaskPii(): boolean {
  return process.env.PII_REDACTION_ENABLED === "true";
}

Cross-Transport Security Enforcement

Whether requests arrive via HTTP, WebSocket, Server-Sent Events (SSE), or the MCP server, OmniRoute invokes the same extractApiKey() and isValidApiKey() functions to guarantee uniform protection. In src/server/ws/liveServer.ts (line 142), the WebSocket live server validates the API key before establishing the connection, ensuring that transport protocol differences do not create security gaps.

Summary

• Secure Extraction: The extractApiKey() function in src/sse/services/auth.ts pulls tokens from headers (Bearer, x-api-key, x-goog-api-key) or path-scoped URLs, never from query strings.
• Encrypted Storage: All API keys reside in an encrypted SQLite database (src/lib/db/apiKeys.ts) using the encryption layer in src/lib/db/encryption.ts.
• Centralized Validation: The isValidApiKey() function validates every request against the secure key store before processing.
• Opt-In Redaction: PII and credential masking guardrails only activate when PII_REDACTION_ENABLED or CREDENTIAL_REDACTION_ENABLED are explicitly set to "true".
• Transport Agnostic: The same security functions enforce protection across HTTP, WebSocket, SSE, and MCP entry points.

Frequently Asked Questions

Does OmniRoute store API keys in plaintext?

No. According to the OmniRoute source code, all API keys are stored in an encrypted SQLite database managed by src/lib/db/apiKeys.ts and src/lib/db/encryption.ts. This encryption layer ensures that keys are never written to disk in plaintext, mitigating risks from file system breaches.

Can API keys be passed via URL query parameters in OmniRoute?

No. The extractApiKey() function in src/sse/services/auth.ts explicitly avoids reading tokens from query strings to prevent accidental exposure in access logs or browser history. The function supports path-scoped tokens for specific integrations like VS Code, but only when explicitly enabled with the allowUrl option.

How does OmniRoute handle API key validation for WebSocket connections?

WebSocket connections use the same validation pipeline as HTTP requests. In src/server/ws/liveServer.ts (line 142), the server invokes extractApiKey() and isValidApiKey() before establishing the connection. This ensures that transport protocol differences do not create security gaps or bypass validation requirements.

What controls the credential redaction features in OmniRoute?

Credential and PII redaction are controlled by environment variables. The PII_Masker checks PII_REDACTION_ENABLED and the Credential_Masker checks CREDENTIAL_REDACTION_ENABLED, both defaulting to false. These guardrails only activate when explicitly enabled, preventing unintentional data masking in development or debugging scenarios.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}