React Server Components: patrones seguros en producción

React Server Components (RSC) prometen menos JS en cliente — equipos en San Juan adoptan Next.js App Router sin entender que server components aún pueden filtrar datos si diseño es incorrecto. OWASP advierte sobre exposure of sensitive data; un RSC que pasa objeto user completo a client component hijo expone campos internos en bundle.

Patrón seguro: fetch en server component con auth check en mismo boundary; pase al client solo DTO mínimo serializable. Nunca importe módulos con secrets en archivos que terminan referenciados desde 'use client'. El AWS Security Blog aplica el mismo principio en Lambda — mínimo privilegio de datos en cada capa.

Validación: Zod en server action y server component loader; rechace input antes de query DB. SQL injection en RSC es tan real como en API route — ORMs no salvan queries raw en route handlers. Rate limit server actions que mutan estado — son endpoints sin URL visible pero igual atacables.

Caching peligroso: revalidatePath agresivo puede servir datos de usuario A a usuario B si cache keys mal configuradas — use cache: 'no-store' en datos autenticados hasta dominar semantics. Smashing Magazine cubre RSC performance; complemente con threat modeling de data flow.

Audite bundle: busque API keys y PII en client chunks con source-map-explorer. Bruce Schneier recomienda asumir que todo lo enviado al cliente es público — RSC no cambia esa regla, solo reduce volumen. Producción segura en PR requiere code review checklist RSC en cada PR con auth o PII.