rsc-shield

Stop leaking sensitive data from your Server Components.

Why I built this

I kept making the same mistake. I'd write a Server Action, fetch a user from the database, and return it. Simple, right?

'use server';

export async function getUser(id: string) {
  const user = await db.users.find(id);
  return user; // whoops - this has the password hash, SSN, everything
}

The thing is, Server Actions serialize everything you return. There's no filter. Whatever your ORM gives you goes straight to the browser.

I got tired of manually picking fields, so I made this.

What it does

Wrap your action, tell it what's safe to expose:

import { shield } from 'rsc-shield';

export const getUser = shield(
  async (id: string) => {
    return await db.users.find(id);
  },
  { allow: ['id', 'name', 'email', 'avatar'] }
);

That's it. Only those four fields make it to the client. Everything else gets dropped.

Install

npm install rsc-shield

Basic usage

'use server';

import { shield } from 'rsc-shield';

export const getUser = shield(
  async (id: string) => {
    const user = await db.users.findUnique({ where: { id } });
    return user;
  },
  { allow: ['id', 'name', 'email'] }
);

Besides filtering keys, it also strips out stuff that can't be serialized anyway:

• Functions
• Symbols
• Class instances (Map, Set, custom classes)
• Anything that's not plain JSON (except Dates - those work fine)

Using with Zod

If you're already using Zod, you can pass a schema instead:

'use server';

import { shield } from 'rsc-shield';
import { z } from 'zod';

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string().email(),
  role: z.enum(['user', 'admin']),
}).strip();

export const getUser = shield(
  async (id: string) => {
    const user = await db.users.findUnique({ where: { id } });
    return user;
  },
  { schema: UserSchema }
);

The .strip() is important - it tells Zod to remove any fields not in the schema.

If validation fails, you get a ShieldValidationError. In dev, it shows what went wrong. In production, it just says "Internal Server Error" so you don't accidentally leak info through error messages.

Debug mode

When things aren't working, turn on debug:

export const getUser = shield(
  async (id: string) => {
    return await db.users.find(id);
  },
  {
    allow: ['id', 'name'],
    debug: true,
  }
);

You'll see exactly what got stripped:

[rsc-shield] Original result: { id: 1, name: 'John', password: 'secret', ... }
[rsc-shield] Stripped keys: ['password (not in allowed keys)', 'ssn (not in allowed keys)']
[rsc-shield] Sanitized result: { id: 1, name: 'John' }

Taint API

React 18.3+ has an experimental "taint" API that lets you mark values as unsafe to pass to Client Components. We wrap it:

import { taintKeys } from 'rsc-shield';

async function getUser(id: string) {
  const user = await db.users.find(id);

  // mark these as "do not send to client"
  taintKeys(user, ['password', 'ssn', 'apiKey'], 'Sensitive data');

  return user;
}

If those values somehow end up in a Client Component, React throws. It's a nice safety net on top of the sanitization.

API

shield(action, options?)

Wraps an async function. Returns a new function with the same signature.

Options:

• allow - array of top-level keys to keep
• schema - Zod schema (or anything with .parse() / .safeParse())
• debug - log what's happening

const safeAction = shield(myAction, {
  allow: ['id', 'name'],
  debug: process.env.NODE_ENV === 'development',
});

sanitize(data, allowedKeys?)

If you just want to sanitize data without wrapping a function:

import { sanitize } from 'rsc-shield';

const clean = sanitize(dirtyData, ['id', 'name']);

taintObject(value, message)

Mark a single value as tainted:

taintObject(user.password, 'Do not send password to client');

taintKeys(obj, keys, message?)

Mark multiple values at once:

taintKeys(user, ['password', 'ssn'], 'Sensitive');

ShieldValidationError

Thrown when schema validation fails. Has an originalError property with the actual Zod error (in dev).

How it works

1. Your action runs and returns data
2. If you provided a schema, it validates (and potentially transforms) the data
3. The sanitizer walks through the result, keeping only allowed keys and serializable values
4. The clean data gets returned to the client

Schema validation happens first, so Zod transforms and defaults work as expected.

Framework Patches vs. Application Security

After the December 2025 security patches (CVE-2025-55182 and friends), you might wonder: "Didn't Next.js already fix RSC security issues?"

Yes and no. Here's the difference:

| What | Framework Patches (Dec 2025) | rsc-shield | |------|------------------------------|------------| | Problem | Remote Code Execution, DoS attacks via Flight protocol | Accidental data exposure from developer mistakes | | Threat | Malicious actors exploiting protocol bugs | Your own code returning user.password by accident | | Fix | Patched at runtime level | Sanitizes at application level |

The framework can't read your mind. Next.js doesn't know that user.ssn shouldn't go to the browser — only you do. That's where rsc-shield comes in.

It also helps with ongoing issues like CVE-2025-55183 (source code exposure in error messages). Even with patched frameworks, your app can still leak data through:

• Returning full database records instead of DTOs
• Forgetting to filter sensitive fields after a schema change
• Error messages that include internal state

Frameworks fix the door. rsc-shield locks the safe.

License

MIT © 2025 heysaiyad

If this helped you ship safer code, consider giving it a ⭐ on GitHub — it means a lot!

Report a bug · Request a feature