Fix Business Logic Errors in RedwoodJS

RedwoodJS services are the heart of your application's business logic, but they are often the weakest link. Developers frequently mistake GraphQL 'requireAuth' directives for complete security. While directives handle authentication, they don't handle granular authorization. The most common failure is IDOR (Insecure Direct Object Reference) where a user can manipulate records belonging to others by simply guessing an ID. To fix this, you must shift from 'can they access this function' to 'can they access this specific record'.

The Vulnerable Pattern

export const updatePost = ({ id, input }) => {
  // VULNERABLE: Trusting the 'id' from the client without checking ownership.
  return db.post.update({
    data: input,
    where: { id },
  })
}

The Secure Implementation

The vulnerable code assumes that because the user is logged in, they have the right to modify any 'id' they provide. This allows an attacker to iterate through IDs and overwrite arbitrary data. The secure implementation uses the RedwoodJS 'context' object—which is populated server-side and cannot be spoofed by the client—to verify that the 'userId' of the record matches the 'id' of the authenticated user. By performing this check at the service layer, you ensure that business rules are enforced regardless of how the GraphQL API is queried.

import { forbidden } from '@redwoodjs/graphql-server'
export const updatePost = async ({ id, input }) => {
// SECURE: Fetch the record and verify ownership against the global context
const post = await db.post.findUnique({ where: { id } })
if (!post) {
throw new Error(‘Post not found’)
}
if (post.userId !== context.currentUser.id) {
// Log the attempted breach and deny access
forbidden(‘You do not have permission to update this post.’)
}
return db.post.update({
data: input,
where: { id },
})
}