agentsclimarketplace

Database security

Skill Rootx202/appsec-skills/database-security

AppSec Skills — 15 plug-and-play Claude Code security skills that audit, harden, and fix any website or app before you ship it. OWASP Top 10, auth, API, database, frontend, backend, cloud, dependencies, secrets, and pentest-style checks — all defensive, all evidence-based.

Install
npx -y skills add Rootx202/appsec-skills --skill database-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

3 things to look at

  • 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Database security auditor covering PostgreSQL, MySQL, SQL Server, MongoDB, and Supabase/Firebase-style backends. Use when the user asks about database security, Row Level Security (RLS) policies, exposed database access, ORM-related SQL injection, or backend-as-a-service data access rules for any project.

SKILL.md

2.9 KB, as published. Nobody here has run it

Database Security — Data Layer Auditor

A specialized skill for auditing the database layer: permissions, policies, queries, and data exposure.

When to use this

  • Any project using PostgreSQL/MySQL/MongoDB/SQL Server or a BaaS like Supabase/Firebase
  • Reviewing Row Level Security (RLS) or equivalent row-level access rules
  • Suspected data leakage or excessive permissions

Core Checks

SQL / NoSQL Injection

  • Any query built via string concatenation with user input is a likely vulnerability — require parameterized queries or a correctly used ORM (Prisma, Drizzle, TypeORM, SQLAlchemy, Mongoose).
  • Watch for "safe-looking but not" escape hatches: many ORMs expose raw()/$queryRaw/.raw() that bypass protection if fed unsanitized input.

Row Level Security (Postgres/Supabase-style backends)

  • Is RLS enabled on every table containing user data? (Enabling RLS with no policies blocks everything — but forgetting to enable it is often catastrophic.)
  • Are SELECT/INSERT/UPDATE/DELETE policies written precisely (auth.uid() = user_id) instead of a blanket true policy?
  • Is a service-role / admin key (which bypasses RLS) ever used in client-side code? This is always Critical — such keys must stay server-side only.

Permissions and Roles

  • Principle of least privilege: the application's runtime DB user should not have DROP/ALTER on tables it doesn't need to modify structurally.
  • Separate read/write roles where appropriate.

Database Exposure

  • Is the database port open to the public internet without IP restrictions?
  • Is the connection string kept only in environment variables — never committed to source control or config files checked into git?

Sensitive Data

  • Encryption at rest for especially sensitive fields when the regulatory/business context calls for it
  • Passwords never stored in plaintext (details covered in authentication-security)

Weak or Costly Queries

  • Unbounded queries (missing LIMIT) on large tables that could enable denial-of-service
  • Missing indexes on columns used frequently in permission-related filters (can slow down RLS checks and become a performance-driven weakness)

Report Format

Table/Query: [name]
Issue: [problem]
Severity: Critical/High/Medium/Low
Evidence: [the policy or query in question]
Impact: [e.g., any authenticated user can read every other user's data]
Fix: [corrected policy or query]

Rules

  • When reviewing a BaaS like Supabase, ask to see the actual migration files or RLS policies rather than assuming their content.
  • Never write actual exploitation queries against systems the user doesn't own.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.