auth-rls-boundary-hardening

Hardens Better Auth and RLS boundaries with fail-fast validation, audit logging, and regression tests.

Updated Jul 21, 2026
One-click install
npx skills add https://github.com/masakinihirota/2026src-ni --skill auth-rls-boundary-hardening-masakinihirota
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: auth-rls-boundary-hardening
Source: https://github.com/masakinihirota/2026src-ni/tree/main/.agents/skills/auth-rls-boundary-hardening
Command: npx skills add https://github.com/masakinihirota/2026src-ni --skill auth-rls-boundary-hardening-masakinihirota

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Authentication and database row-level security boundaries often fail silently: default credentials slip into production, empty authUserId values get written into RLS session variables, and session failures go unlogged. This Skill prevents those incidents by enforcing fail-fast configuration, input validation, audit logging, and minimal regression tests. ## Core Features & Use Cases - Fail-fast credential checks: Throws errors when OAuth clientId/clientSecret or secrets are missing instead of falling back to defaults, and flags trustedOrigins/baseURL mismatches. - RLS context validation: Rejects empty, null, or undefined authUserId values before calling set_config('app.auth_user_id'), and requires per-request RLS context initialization. - Audit logging for auth failures: Records path, method, and IP via a structured logger whenever session retrieval fails. - Use Case: A Next.js app using Better Auth passes session user IDs into Postgres RLS via set_config. Apply this Skill to add a Vitest regression test proving empty authUserId throws, then harden the middleware and DB context layers. ## Quick Start Ask the agent to audit the Better Auth configuration and RLS context code for missing fail-fast checks, authUserId validation, and audit logging, then add a minimal regression test.

Frequently Asked Questions about auth-rls-boundary-hardening

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I pass the Better Auth user ID into Postgres RLS safely?▼

Validate that authUserId is a non-empty string before calling set_config('app.auth_user_id', authUserId, true) inside the transaction. Initialize the RLS context explicitly on every request so no stale or missing identity leaks across queries.

How do I prevent default OAuth credentials from reaching production?▼

Use fail-fast checks at startup: if GOOGLE_CLIENT_ID or GOOGLE_CLIENT_SECRET are unset, throw an error immediately instead of falling back to defaults. Also verify trustedOrigins and baseURL are consistent with the deployment environment.

What should I log when a Better Auth session lookup fails?▼

Log a structured warning such as auth_session_failed with minimal context: request path, HTTP method, and client IP from x-forwarded-for. Use a logger rather than console output so failures are captured by your observability pipeline.

Why is setting an empty authUserId into RLS dangerous?▼

An empty or undefined authUserId in app.auth_user_id can silently disable row-level filtering or misattribute rows, exposing data across tenants. Validating the value before set_config turns this silent failure into an explicit, testable error.

What regression tests should I add after fixing an auth/RLS bug?▼

Add one minimal failing test first (RED), such as asserting setRlsContext rejects an empty authUserId, then make it pass with the smallest fix (GREEN). Only refactor shared validation logic afterward, and check adjacent layers like middleware and DB context.