Skip to content

security.mdx

Latest commit

 

History

History
105 lines (74 loc) · 3.58 KB

security.mdx

File metadata and controls

105 lines (74 loc) · 3.58 KB
title Security
description How urBackend protects your project: dual API keys, injection prevention, rate limiting, and key storage best practices.

Dual-key system

Every urBackend project has two API keys with different trust levels. Use the right key in the right environment.

Key type Prefix Where to use Access level
Publishable pk_live_ Frontend / mobile clients Read by default; writes only with RLS + user JWT
Secret sk_live_ Server-side / backend only Full read/write access (CRUD)
**Never expose your `sk_live_` key in frontend code or version control.** If committed to a public repository, rotate it immediately from the Dashboard.

NoSQL injection prevention

urBackend sanitizes top-level JSON keys that begin with $ before they reach your database. This prevents common MongoDB operator injection attacks such as { "$where": "..." }.

Nested object keys are not yet recursively sanitized. Validate and sanitize nested user input in your own application logic until recursive sanitization is added.

Rate limiting

urBackend enforces rate limits per IP address to protect against DDoS attacks and brute-force attempts.

Endpoint group Limit
Global API 100 requests per 15 minutes per IP
Auth endpoints (/api/userAuth/*) Stricter per-IP limit

When you exceed the limit, the API returns 429 Too Many Requests. If you are using the SDK, catch RateLimitError:

import { RateLimitError } from '@urbackend/sdk';

try {
  await client.db.getAll('products');
} catch (e) {
  if (e instanceof RateLimitError) {
    // Back off and retry after the window resets
  }
}

Domain whitelisting

You can restrict API access to specific domains from the Dashboard → Project Settings. When you enable domain whitelisting, urBackend rejects any request whose Origin header does not match your allowlist.

This prevents other websites from using your pk_live_ key to make unauthorized requests to your project.

Schema enforcement

When you define a schema for a collection, urBackend validates every incoming document against your schema before saving. Documents with wrong field types, missing required fields, or unexpected structure are rejected at the API layer — no extra validation code needed on your end.

Special case: the users collection

Direct access to /api/data/users* is intentionally blocked. You cannot read, write, or query user records through the data API.

All user-related operations must go through the dedicated auth endpoints:

POST /api/userAuth/signup    — register a new user
POST /api/userAuth/login     — log in; returns { token, user }
GET  /api/userAuth/me        — get current user profile
This restriction exists to prevent accidental exposure of password hashes and other sensitive user fields through the general-purpose data API.

Key storage best practices

Store your API keys in environment variables, never hard-coded in source files.

# .env
URBACKEND_PUBLISHABLE_KEY=pk_live_...
URBACKEND_SECRET_KEY=sk_live_...

Then reference them in your code:

const client = urBackend({
  apiKey: process.env.URBACKEND_SECRET_KEY,
});

Add .env to your .gitignore to prevent accidental commits:

# .gitignore
.env
.env.local
.env.*.local
If you use a CI/CD platform, store your `sk_live_` key as an encrypted secret (e.g., GitHub Actions Secrets, Vercel Environment Variables) rather than in a `.env` file checked into your repository.