Security Update: Error Message Safety in API Endpoints

Release v1.0.417 · SEC-23 · Data Protection

Overview

This release closes a data-protection gap where raw database error messages could be returned to callers of the POST /api/migrate endpoint. The fix ensures that internal implementation details — schema names, column names, constraint identifiers, and connection strings — remain server-side and are never disclosed in HTTP responses.

Background

When a database migration fails, the underlying error thrown by the database driver typically contains detailed diagnostic information. This is valuable for debugging, but it is not information that should leave the server boundary. Prior to this release, the migrate endpoint's catch block forwarded this detail verbatim:

// Before — raw error message returned to caller
return NextResponse.json(
  { error: err instanceof Error ? err.message : String(err) },
  { status: 500 }
);

Although POST /api/migrate is protected by a bearer token (the migration secret), returning internal error detail to any token holder — or to an attacker who has obtained the secret — violates the principle of minimal disclosure and increases the value of credential compromise.

What Was Fixed

The error handler in src/app/api/migrate/route.ts has been updated to:

1. Return a generic message in the HTTP response body — no schema, column, constraint, or connection information is included.
2. Log the full error server-side — operators and on-call engineers can still diagnose failures through server logs without any change to observability.

// After — generic message to caller, full detail in server logs
catch (err) {
  console.error('[migrate] Migration failed:', err);
  return NextResponse.json(
    { error: 'Migration failed. Check server logs for details.' },
    { status: 500 }
  );
}

Why This Matters

• Schema leakage — Table and column names reveal the data model and can assist targeted injection or enumeration attacks.
• Constraint names — Named constraints (e.g. uq_users_email) expose business-logic assumptions.
• Connection strings — In some driver configurations, connection errors include the host, port, or database name.
• Consistency — This pattern was already applied to other endpoints (SEC-05). Uniform error handling reduces the surface area for future disclosures.

No Action Required

This is a server-side fix. No client changes, credential rotations, or configuration updates are needed. If you operate a self-hosted instance, deploy v1.0.417 to pick up the fix.

Reporting Security Issues

If you discover a security vulnerability in the platform, please follow responsible disclosure and contact the security team directly rather than opening a public issue.