Fix Improper Error Handling in RedwoodJS

RedwoodJS applications frequently leak sensitive database schema details and stack traces via GraphQL responses when exceptions aren't properly sanitized. In the API side, raw Prisma errors or generic JavaScript errors can expose internal logic, table structures, and environment details to an attacker. Securing this requires intercepting internal exceptions and mapping them to sanitized, client-safe RedwoodGraphQLError instances.

The Vulnerable Pattern

// api/src/services/users/users.js
export const deleteUser = ({ id }) => {
  try {
    return db.user.delete({ where: { id } })
  } catch (e) {
    // VULNERABILITY: This re-throws a raw Prisma error.
    // The GraphQL response will contain internal DB constraints and table names.
    throw new Error(e)
  }
}

The Secure Implementation

The vulnerable example pipes the raw Prisma exception directly into a generic Error object. Redwood's GraphQL handler, by default, may serialize these details into the 'errors' array of the JSON response, providing a roadmap for SQL injection or schema enumeration. The secure implementation uses 'RedwoodGraphQLError' to decouple the internal failure from the public API response. It ensures that sensitive metadata stays in the server-side logs while the client receives a non-descriptive, hardened error code.

// api/src/services/users/users.js
import { RedwoodGraphQLError } from '@redwoodjs/graphql-server'
import { logger } from 'src/lib/logger'
export const deleteUser = async ({ id }) => {
try {
return await db.user.delete({ where: { id } })
} catch (e) {
// LOG: Keep the detailed error in your server logs for debugging
logger.error(e, ‘Failed to delete user’)
// SANITIZE: Throw a generic error to the client
throw new RedwoodGraphQLError('User deletion failed.', {
  code: 'UNPROCESSABLE_ENTITY',
  extensions: { message: 'The requested operation could not be completed.' }
})
}
}