Security, Rate Limits, and Process Guards

Oddity 1 implements a multi-layered security architecture to protect API resources, manage Large Language Model (LLM) costs, and ensure system stability. This system coordinates authentication via Supabase, enforces tiered rate limits on the client and server, and utilizes process guards to monitor backend health.

The security framework encompasses the Chrome extension's background service worker, which manages OAuth tokens and request throttling, and the Express-based backend, which validates requests and handles upstream LLM provider failures.

Authentication and Authorization

Oddity 1 uses Supabase Auth for user management. The system supports email/password authentication and Google OAuth. The backend identifies users via a Bearer token provided in the Authorization header.

Authentication Flow

The extension background script acts as the primary orchestrator for authentication. It captures session data and provides it to the content scripts and popup.

Auth Tiers and RLS

The system enforces Row Level Security (RLS) within the database. Users can only access their own metadata in the profiles table and their own entries in the user_annotations and annotation_feedback tables.
Sources: README.md:310-320

Rate Limiting and Usage Control

Oddity 1 protects its LLM resources using a two-tier usage system. Limits are enforced based on the user's subscription status (Free vs. Standard/Pro).

Usage Tiers

Sources: README.md:297, CHANGELOG.md:120

Client-Side Throttling

The extension background script implements proactive rate limiting to prevent overwhelming the API. It uses AbortController to cancel stale in-flight requests and a concurrency limiter to manage bursts.

• Concurrency Limit: Maximum of 3 concurrent API requests per tab.
• Retry After: If the server returns an HTTP 429 (Too Many Requests), the client blocks further requests for a duration specified by the retry_after header, capped at 5 minutes (300 seconds).

Backend Process Guards and Stability

The backend utilizes process guards and error handling middleware to maintain high availability.

Process Role Initialization

The backend distinguishes between "app" and "worker" roles. Unless specified as a worker, the system registers process guards that monitor for fatal errors.
Sources: backend/api/index.ts:25-28

LLM Error Resilience

The openrouter.js client (tested in openrouter.test.ts) implements several fallback mechanisms for LLM interactions:

1. Buffered Fallback: If a streaming response fails or encounters a parse error, the system automatically retries using a standard buffered JSON request.
2. Key Rotation: The backend can rotate through backup API keys (OPENROUTER_API_KEY_BACKUP1, etc.) if the primary key encounters rate limits (HTTP 429) from the upstream provider.
3. Permanent Error Detection: Upstream authentication failures (HTTP 401) are treated as permanent and do not trigger retries.

Sources: backend/lib/tests/openrouter.test.ts:133-160, backend/lib/tests/openrouter.test.ts:186-210

CORS and Network Security

The backend restricts cross-origin resource sharing (CORS) to trusted domains to prevent unauthorized web-based access.

• Allowed Origins: Includes the official dashboard (https://app.oddity1.com) and environment-specific DASHBOARD_URL.
• Extension Access: CORS allows requests with no origin, facilitating communication from the Chrome extension and server-to-server calls.
• Body Limits:
  • Global: 2MB limit.
  • PDF Conversion: 4.5MB limit to accommodate binary data.

Sources: backend/api/index.ts:33-65

Conclusion

The security architecture of Oddity 1 ensures that AI resource consumption remains within sustainable limits while providing a resilient experience. By combining Supabase JWT validation, multi-stage rate limiting, and automated LLM provider failover, the system maintains stability even during high load or upstream service disruptions.