Codapult
料金プラグインドキュメント
Codapult

開発者のためのSaaSボイラープレート

プロダクト

  • 料金
  • プラグイン
  • ドキュメント

会社情報

  • お問い合わせ
  • GitHub

法的情報

  • プライバシーポリシー
  • 利用規約

© 2026 Codapult. All rights reserved.

全記事

Getting Started

  • Introduction
  • Quick Start
  • Project Structure

Configuration

  • Environment Variables
  • App Configuration

Authentication

  • Authentication
  • OAuth Providers
  • Two-Factor & Passwordless
  • Enterprise SSO (SAML)

Database

  • Database
  • Migrations

Teams

  • Teams & Organizations
  • Permissions & RBAC

Payments

  • Payments & Billing
  • Stripe Setup
  • LemonSqueezy Setup
  • Polar Setup
  • Payment Webhooks

Api

  • API Layer
  • tRPC
  • GraphQL

Ai

  • AI Features

Email

  • Email
  • Email Templates

Infrastructure

  • Infrastructure
  • File Storage
  • Background Jobs

Ui

  • UI & Theming

I18n

  • Internationalization

Content Management

  • Content Management

Admin

  • Admin Panel

Security

  • Security

Monitoring

  • Analytics & Monitoring

Modules

  • Module Architecture

Plugins

  • Plugin System
  • AI Kit Plugin
  • CRM Plugin
  • Helpdesk Plugin
  • Email Marketing Plugin

Deployment

  • Deployment
  • Troubleshooting

Upgrading

  • Upgrading Codapult

Developer Tools

  • MCP Server
  • Testing
Security

Security

HTTP headers, rate limiting, auth guards, input validation, GDPR compliance, and API key management.

Codapult ships with multiple layers of security enabled by default — HTTP headers, rate limiting, auth guards, input validation, and data privacy controls. No extra configuration is needed for the baseline protections.


HTTP Security Headers

The following headers are set on all responses via next.config.ts:

HeaderValuePurpose
X-Content-Type-OptionsnosniffPrevents MIME-type sniffing
X-Frame-OptionsDENYBlocks clickjacking via iframes
Strict-Transport-Securitymax-age=63072000; includeSubDomains; preloadEnforces HTTPS
Referrer-Policystrict-origin-when-cross-originLimits referrer information leakage
Permissions-PolicyRestrictive defaultsDisables unused browser APIs
X-DNS-Prefetch-ControlonControls DNS prefetching behavior

Rate Limiting

A sliding-window rate limiter (src/lib/rate-limit.ts) protects against abuse. It is applied to:

  • Auth endpoints (sign in, sign up, magic link, 2FA)
  • AI chat API
  • Billing and checkout routes
  • Admin actions
  • GraphQL endpoint
  • Plugin catch-all routes
  • SSO authorize and callback
  • Notification stream (SSE)
  • Custom domain management

Usage

import { checkRateLimit } from '@/lib/rate-limit';

const { allowed, remaining, resetAt } = checkRateLimit(`api:${session.user.id}`, {
  limit: 30,
  windowSeconds: 60,
});

if (!allowed) {
  return NextResponse.json(
    { error: 'Too many requests. Please wait a moment.' },
    {
      status: 429,
      headers: {
        'Retry-After': String(Math.ceil((resetAt - Date.now()) / 1000)),
      },
    },
  );
}

Rate-limit state is stored in memory by default. For multi-instance deployments, you would need to implement a Redis-backed storage adapter (e.g. using Upstash or ioredis) — this is not included out of the box.


Auth Guards

Server-side guards in src/lib/guards.ts protect server actions and API routes. Use these instead of writing manual session checks:

GuardDescription
requireAuth()Ensures the user is authenticated. Throws if no session.
requireOrgPermission(orgId, permission)Checks the user has a specific permission within the given organization.
requireOrgMembership(orgId)Verifies the user is a member of the given organization.
requireOrgAdmin(orgId)Verifies the user is an admin of the given organization.

Example

import { requireAuth, requireOrgPermission } from '@/lib/guards';

export async function updateProject(orgId: string, data: unknown) {
  await requireAuth();
  await requireOrgPermission(orgId, 'projects:write');

  // Safe to proceed — user is authenticated and authorized
}

Input Validation

All server actions and API routes validate input with Zod schemas defined in src/lib/validation.ts. Never trust raw user input:

import { updateProfileSchema } from '@/lib/validation';

export async function updateProfile(data: unknown) {
  const validated = updateProfileSchema.parse(data);
  // Use validated.name, validated.email, etc.
}

Zod throws a ZodError on invalid input, which is caught by the error boundary and returned as a structured error response.


Branding CSS Sanitization

When applying custom branding (white-label colors and class names), Codapult sanitizes all values before injection:

  • brandingToCssVars() — validates color values against an allowlist regex before injecting them via dangerouslySetInnerHTML. Only valid CSS color formats are accepted.
  • sanitizeCustomClass() — ensures custom class names contain only safe characters (letters, digits, hyphens, underscores).

This prevents CSS injection attacks through the branding configuration.


GDPR Compliance

Codapult includes built-in data privacy controls in src/lib/gdpr/:

EndpointMethodDescription
/api/account/exportGETExports all user data as a downloadable JSON file
/api/account/deletePOSTPermanently deletes the user account and all associated data

Both endpoints require authentication and only operate on the authenticated user's own data.


API Keys

Personal API keys (src/lib/api-keys.ts) allow programmatic access to the API:

  • Keys are hashed before storage — the raw key is shown once at creation and cannot be retrieved later
  • Each key is scoped to a single user
  • Keys can be revoked from the dashboard settings

SCIM Provisioning

For enterprise customers, Codapult supports SCIM (System for Cross-domain Identity Management) in src/lib/scim/. This enables automated user provisioning and deprovisioning from identity providers like Okta, Azure AD, and OneLogin.


Secrets Management

Follow these rules to prevent accidental secret exposure:

  • Never use NEXT_PUBLIC_ prefix for secrets. Variables with this prefix are bundled into client-side JavaScript and visible to anyone.
  • Access env vars through src/lib/config.ts for type-safe, validated access on the server.
  • Error responses must not expose internals. Always return { error: string } — never stack traces, file paths, or database details.

Checklist

Use this checklist when adding new features:

  • Auth guard (requireAuth or requireOrgPermission) on every protected route/action
  • Zod validation on all user input
  • Rate limiting on public-facing endpoints
  • No secrets in NEXT_PUBLIC_ variables
  • Error responses reveal no internal details
  • File uploads validated (size, type) before storage

Next Steps

  • Environment Variables — configure SSO, API keys, and security-related env vars
  • Admin Panel — user management, feature flags, and audit log
  • Analytics & Monitoring — error tracking with Sentry and performance monitoring
Admin PanelAnalytics & Monitoring