/nestjs-security-isolation

Enforce multi-tenant isolation and PostgreSQL Row Level Security in NestJS. Use when enforcing tenant isolation or PostgreSQL RLS in NestJS multi-tenant apps.

hoangnguyen0403@hoangnguyen0403

GitHub

From plugin

agent-skills-standard

538200 skills1 MCP

Install

$ npx -y skills add hoangnguyen0403/agent-skills-standard --skill nestjs-security-isolation --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/nestjs-security-isolation

Context preview

The summary Claude sees to decide when to auto-load this skill.

Enforce multi-tenant isolation and PostgreSQL Row Level Security in NestJS. Use when enforcing tenant isolation or PostgreSQL RLS in NestJS multi-tenant apps.

SKILL.md

nestjs-security-isolation.SKILL.md

name: nestjs-security-isolation
description: Enforce multi-tenant isolation and PostgreSQL Row Level Security in NestJS. Use when enforcing tenant isolation or PostgreSQL RLS in NestJS multi-tenant apps.
metadata:
  triggers:
    files:
    - 'src/modules/**'
    - 'SECURITY.md'
    - 'src/migrations/**'
    keywords:
    - RLS
    - Row Level Security
    - childId
    - isolation
    - access policy

Priority: P0 (CRITICAL)

Strict multi-tenant isolation. All child-centric data must secured via PostgreSQL RLS and service-level validation.

RLS Enforcement Workflow

1. **Migration**: Create tables with `ENABLE ROW LEVEL SECURITY`. Define policies using `current_setting('app.current_user_id')`. 2. **Entity Logic**: Add `@Security` JSDoc to entity class. 3. **Security Doc**: Update `SECURITY.md` with new table and its access logic. 4. **Service Validation**: Call `childrenService.validateChildAccess(childId, userId)` before any persistence operation.

Core Guidelines

1. **Mandatory RLS**: Every new table linking to `child` or `family` MUST RLS enabled in its creation migration. 2. **Centralized Validation**: Never reimplement access logic. Use `ChildrenService` for child/family membership checks. 3. **Traceable Security**: `SECURITY.md` source of truth. Any change to RLS policies must reflected there immediately. 4. **Nested Route Constraint**: Data isolation enforced at controller level via nested routes: `/children/:childId/...`. 5. **No Direct Entity exposure**: Use Response DTOs to prevent leaking internal database IDs or metadata that could circumvent security checks.

Anti-Patterns

**No Public Tables**: Don't create child-linked tables without RLS.
**No Manual Policy Checks**: Don't write raw SQL access checks in services. Use centralized validator.
**No Stale Docs**: Don't merge RLS changes without updating `SECURITY.md` and entity JSDoc.
**No Root IDs**: Don't use `/domain/:id` for child data. Always scope by `:childId`.