Security Overview

Security architecture, threat model, and controls implemented in the NIN Connect platform.

Overview

NIN Connect handles OAuth tokens, API keys, and user credentials on behalf of developers. That makes security the foundation the entire platform sits on, not an add-on.

This section documents every security control built into the platform so you can audit the implementation, understand the threat model, and configure your deployment correctly.

Threat Model

The platform protects against these threat categories:

Threat	Control
Credential theft at rest	AES-256-GCM encryption for all stored credentials
Credential theft in transit	HTTPS enforcement, HSTS headers
Server-Side Request Forgery (SSRF)	DNS resolution + private IP blocking before all outbound fetches
Unauthenticated credential injection	HMAC-signed connect tokens required for all credential submissions
Open redirect attacks	Redirect URL validation on all OAuth flows
Brute-force and abuse	Per-IP and per-API-key rate limiting
Cross-site attacks (XSS, clickjacking)	CSP, X-Frame-Options, X-Content-Type-Options headers
Cross-origin abuse	Route-specific CORS policies
Input manipulation	Zod validation on every API endpoint
Secret leakage in source	Startup env validation, no fallback keys, `.env` in `.gitignore`
Accountability gaps	Audit logging for all security-relevant events

Security Layers

Request → Security Headers (next.config.ts)
        → Middleware (rate limit, CORS, body size)
        → Route Handler (auth check, Zod validation, connect token)
        → Business Logic (SSRF check, encryption, audit log)

Every request passes through multiple independent layers. A failure in one layer does not compromise the others.

Authentication

The platform uses two independent authentication systems:

Dashboard (Firebase ID Tokens)

Developers sign in via Google through Firebase Authentication. Every dashboard API request includes a Firebase ID token in the Authorization: Bearer header. The server verifies the token using the Firebase Admin SDK and resolves the developer record.

Admin-only routes additionally check that the developer's role field is "admin".

SDK / External Clients (API Keys)

SDK consumers authenticate with API keys prefixed nk_live_. Keys are SHA-256 hashed before storage. The raw key is shown exactly once at creation time and never stored.

Validation flow:

Extract Bearer nk_live_... from the Authorization header
SHA-256 hash the raw key
Look up the hash in the apiKeys table
Return the associated developerId and keyId

Encryption

All credentials are encrypted at rest using AES-256-GCM. The encryption key is a 32-byte value stored as a 64-character hex string in the ENCRYPTION_KEY environment variable.

Ciphertext format: {iv_hex}:{ciphertext_hex}:{auth_tag_hex}

Credentials are only decrypted at the moment of tool execution. They are never exposed through API responses, logs, or any other channel.

See the Auth System page for full details on encryption, OAuth flows, and credential injection.

Reporting Vulnerabilities

If you discover a security issue, do not open a public GitHub issue. Instead, email security@nin.dev with a description, reproduction steps, and potential impact. We acknowledge reports within 48 hours.

Security Overview

On this page