Skip to content
Back to skills

Nestjs Security Isolation

ASecurity

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

  • 549 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added June 6, 2026
developmentsqldatabasesecurity

Security analysis

A100/100

Pro scans all 5 files and shows the line behind each finding

Scanned June 6, 2026

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

Installs into .claude/skills of the current project.

Are you the author of Nestjs Security Isolation?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Nestjs Security Isolation
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hoangnguyen0403-nestjs-security-isolation/badge)](https://www.skillsdirectory.com/skills/hoangnguyen0403-nestjs-security-isolation)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
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 bypass security filters.

## 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`.

## References

- [Implementation Patterns](references/implementation-patterns.md)
- [RLS Migration Patterns](references/rls-patterns.md)
- [Centralized Auth Logic](references/auth-logic.md)

Files in this skill

  • SKILL.md2.1 KB
  • evals/evals.json1.9 KB
  • references/auth-logic.md1 KB
  • references/implementation-patterns.md1.1 KB
  • references/rls-patterns.md923 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.