Skip to content

Security

Jump to bottom
Valerio edited this page Apr 27, 2026 · 1 revision

Security

UncannyPrompt handles prompt content, tenant data, secrets, public links, and API keys. Security is enforced at multiple layers: authentication, authorization, CSRF, rate limiting, secure headers, token hashing, encryption, and audit.

For identity and permission details, see Authentication and Authorization. For the developer-facing API surface, see API.

HTTP-level hardening

Configured in src/UncannyPrompt.WebApp/Program.cs:

Control Behavior
HTTPS redirect Enabled outside development
HSTS Enabled outside development
X-Content-Type-Options nosniff
X-Frame-Options DENY
Referrer-Policy strict-origin-when-cross-origin
CSP Restricts default, script, style, image, and connect sources
Rate limiting fixed windows for API and login routes
Antiforgery enforced for cookie-authenticated mutating JSON requests

Swagger JSON and Swagger UI require an authenticated user.

CSRF

Cookie-authenticated JSON requests are protected by CookieAntiforgeryFilter. Clients must send the antiforgery token in:

X-CSRF-TOKEN

API-key authenticated calls are not cookie sessions and therefore do not use browser CSRF protections.

Rate limiting

Two fixed-window policies are configured:

Policy Limit
api 120 requests per minute
login 12 requests per minute

API controllers use the api policy. Login flows should use the stricter login policy where applicable.

Secret protection

Secret variable values are protected by AesSecretProtector, using key material from:

Security:SecretEncryptionKey

The key must come from environment variables or a secret manager. It must not be hardcoded in appsettings or source-controlled files.

API keys and public tokens

API keys and public share tokens are verified through keyed hashing primitives.

Relevant configuration:

Security:ApiKeyHashKey

API keys can be sent as X-API-Key: <key> or Authorization: Bearer <key>. They authenticate as the owning user and are subject to the same role, tenant, and resource ACL checks as browser sessions. API keys are created and revoked from the authenticated Developers area and the plaintext value is shown only once.

Public links use a two-column model:

  • TokenLookupHash for deterministic indexed lookup;
  • TokenHash for verification after lookup.

This avoids scanning every public link while still keeping raw tokens out of the database.

Audit

Security-relevant events are recorded as AuditEvent rows through IAuditService. Examples include:

  • prompt creation/update/delete actions;
  • sharing and public link changes;
  • successful public link access;
  • access denied decisions;
  • copy/usage events.

Audit pages and APIs should themselves require the appropriate audit.view style permission.

Threat assumptions

UncannyPrompt is designed to mitigate:

  • accidental cross-tenant data exposure;
  • unauthenticated access to private prompts;
  • CSRF against cookie-authenticated users;
  • public link token enumeration;
  • in-memory authorization mistakes by applying access filters in SQL;
  • accidental secret exposure through checked-in configuration.

It does not protect against a fully compromised host process. A host-level attacker can read process memory and environment variables. Production deployments should rely on host hardening, least-privilege credentials, secret managers, network controls, and infrastructure monitoring.

Clone this wiki locally