Security

The app sets strict HTTP headers via next.config.mjs. These apply to every response served by Next.js:

The CSP is intentionally pragmatic rather than nonce-based: SaaSyBase uses inline theme/bootstrap scripts, admin-configurable head/body snippets, analytics, Twitter embeds, and provider checkout scripts. The policy still restricts script, frame, and connect sources to a known allowlist instead of leaving those channels open.

In production, internal error details (stack traces, database errors, validation internals) are never exposed to the client. The error system works in two layers:

import { handleApiError } from '@/lib/api-error';

export async function POST(req: Request) {
  try {
    // ...your logic
  } catch (error) {
    return handleApiError(error);
  }
}

Set ENCRYPTION_SECRET to a strong random string. This key is used for:

• Encrypting sensitive data at rest, including reusable payment authorization codes stored for provider-managed renewals
• Generating HMACs for internal token verification

When using a self-hosted credentials flow, passwords are never stored in plaintext. SaaSyBase hashes credential passwords with bcrypt using 12 salt rounds before they are written to the database.

• Forgot-password tokens are generated with crypto.randomBytes(32)
• Only the SHA-256 hash of the reset token is stored in the database
• Reset links expire after 1 hour and are deleted after use or on expiration
• Password reset increments tokenVersion and deletes active sessions to force re-authentication
• Forgot-password and resend-verification endpoints return generic success messages to reduce email enumeration risk

All incoming payment webhooks are signature-verified before processing. The centralized webhook router at /api/webhooks/payments auto-detects the originating provider from request headers and delegates to the correct signature verification routine.

Webhook secrets support rotation via comma-separated values:

STRIPE_WEBHOOK_SECRET="whsec_new_secret,whsec_old_secret"

During rotation, both the old and new secrets are accepted. Once you've confirmed the new secret works, remove the old one.

Rate limiting is database-backed and distributed-safe (works across serverless instances). Apply it to any API route with a single function call:

import { rateLimit, RATE_LIMITS } from '@/lib/rateLimit';

export async function POST(req: Request) {
  const ip = req.headers.get('x-forwarded-for') ?? 'unknown';
  const limited = await rateLimit(ip, RATE_LIMITS.API_GENERAL);
  if (limited) return limited; // Returns 429 response
  // ...continue
}

If x-forwarded-for is missing, every such request falls into the same fallback bucket. In production, make sure your proxy or platform forwards real client IPs so unrelated users do not share one rate-limit identity.

SaaSyBase ships with six preconfigured tiers:

SaaSyBase includes application-level suspension controls for both users and organization workspaces. These controls are enforced in the app layer, so the behavior stays consistent across Clerk, Better Auth, and NextAuth deployments.

Password policy applies to the app-managed credentials lanes. Clerk handles its own password requirements, while Better Auth and NextAuth use the local password-policy checks.

Active sessions are tracked with device detection and IP-based geolocation:

• Browser name and version
• Operating system
• Approximate geographic location, using IPINFO_LITE_TOKEN when configured and country.is as a fallback
• Last active timestamp

Users see their session history inside /dashboard/profileunder the Security & Data tab.

For the built-in credentials sign-in route, the session cookie is also set with HttpOnly,SameSite=Lax, and the Secure flag on HTTPS deployments.

Geolocation is best-effort. If neither provider returns a result, the session remains valid and the location field is simply left blank.

Moderators have limited admin access — they can manage specific sections without full admin privileges. The system is configurable through the admin panel:

• Assign the MODERATOR role to any user
• Configure which admin sections each moderator can access
• Moderator activity is logged alongside admin actions
• Sections like billing, system settings, and moderator management are admin-only by default

Toggle maintenance mode from the admin panel. When active:

• All public pages redirect to /maintenance and show the branded maintenance screen
• API routes return 503 Service Unavailable as JSON
• Admin routes are exempt — admins can still access the admin panel
• Auth routes, webhook routes, cron, health checks, and /access-denied remain accessible

The feature is DB-backed and controlled via admin settings rather than an environment variable or restart-only flag. Enforcement happens in middleware.

Because the setting lives in the shared database, changes take effect across running instances without a rebuild. The important prerequisite is that every instance points at the same database.

The built-in password policy enforces:

• Minimum 8 characters
• At least one uppercase letter, one lowercase letter, and one number
• Configurable requirements via lib/password-policy.ts

All API input is validated with Zod schemas defined in lib/validation.ts. Never trust raw request bodies:

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

export async function POST(req: Request) {
  const body = await req.json();
  const parsed = someSchema.parse(body);
  // parsed is now typed and validated
}

Zod validation errors are automatically caught by handleApiError() and returned as 400 Bad Request with field-level error messages.