You're protecting your data wrong – Introducing the Protected Query Pattern

Summary

Securing modern full-stack applications can be complex. You have to manage authorizations in many different contexts from UI to data mutation functions. In all of these contexts, you are required to query data and authorize access to it, maybe even conditionally redact and filter parts of it. This problem seems simple initially, but may quickly grow into a difficult beast to maintain and understand in real production applications with complex and ever changing requirements. This guide introduces the protected query pattern as a solution to this problem. Note: This guide views the problem from the perspective of full-stack web applications, such as ones built with Next.js, however this is fully applicable to any application with server-side data fetching. This guide will use Kilpi to implement strong authorizations, however the concepts can be transferred to your projects with or without using it. Protecting your queries To start off, you need a data access layer. This is non-negotiable for well-structured applications to properly secure your data. Scattered SQL queries across your codebase will most likely lead to unmaintainable authorization, even data leaks. When and where to protect your data? Commonly, applications write queries and authorize the data when called as shown in the diagram below. This is simple to implement but starts becoming difficult to maintain as your application grows. Every time you call getDocument(), you also have to duplicate the authorization logic, which makes maintenance error prone and developer mistakes more likely. export async function DocumentPage({ id }) { // All this extra authorization logic shouldn't belong in the component. const user = await getCurrentUser(); const document = await getDocument(id); if (!(user.isAdmin || document.authorId === user.id)) { // Only now we're able to do what this component is supposed to do return <div>{document.title}</div> Authorization directly in the query? The first alternative would be to i...