agentsclimarketplace

Backend security

Skill Rootx202/appsec-skills/backend-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 backend-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

Backend/server-side security auditor for Node.js, Express, NestJS, FastAPI, Django, Flask, Spring, Ruby on Rails, and similar frameworks. Use when reviewing server-side application logic, error handling, logging, file upload handling, or general middleware configuration specifically — separate from database or API-contract concerns.

SKILL.md

3.0 KB, as published. Nobody here has run it

Backend Security — Server-Side Application Layer Auditor

A specialized skill for auditing the application layer running on the server, across common frameworks.

When to use this

  • Any Node.js/Express/NestJS/FastAPI/Django/Flask/Spring/Rails project
  • Reviewing error handling and logging practices
  • Reviewing general middleware configuration (helmet, cors, rate-limit, etc.)

Core Checks

Secure Defaults

  • Node/Express: is helmet (or equivalent) enabled to set security headers?
  • Is a debug/development mode accidentally left on in production? (Django DEBUG=True, Flask debug=True, verbose framework error pages in production all leak sensitive internals.)

Error Handling

  • User-facing errors are generic ("Something went wrong") while full details/stack traces go only to internal logs.
  • No library/framework version numbers leaked in error messages (makes it trivial for an attacker to look up known CVEs for that exact version).

Logging

  • No sensitive data (passwords, tokens, card numbers) ever written to logs, even partially.
  • Security-relevant events are logged: repeated failed logins, permission changes, bulk deletions.
  • Log files/streams are access-restricted, not publicly reachable.

Server-Side Input Validation

  • Every controller/route handler validates type and shape of incoming data — never relies solely on client-side validation.
  • Mass-assignment protection: don't accept updates to fields that weren't explicitly whitelisted (e.g., a generic body update accidentally allowing a role field to be changed).

Rate Limiting & Abuse Protection

  • Application-level rate limits on sensitive/expensive operations (search, bulk export, messaging) per user/IP.
  • Sensible timeouts to prevent resource exhaustion.

File Uploads

  • Actual file type verified via magic bytes, not just the extension or the client-declared Content-Type.
  • Uploaded files stored outside any executable/servable directory, with randomized (not user-controlled) filenames.
  • Enforced maximum file size to prevent denial-of-service.

Internal Service-to-Service Calls (Microservices)

  • Internal calls that assume full mutual trust without any verification are risky if one service is compromised — consider mTLS or internal service tokens where the architecture warrants it.

Report Format

Module/Route: [name]
Issue: [problem]
Severity: Critical/High/Medium/Low
Evidence: [code or configuration]
Impact: [impact]
Fix: [remediation]

Rules

  • Stay focused on application/server logic; hand off infrastructure/cloud config issues to cloud-security, and database-layer issues to database-security.

Gives 0 of the 12 instructions most security skills give

Counted across 648 of the 828 authors here whose files we hold, read 2026-08-06

  • parameterize all database queriesin 67 of 648, across 49 files
  • hash passwords using bcrypt scrypt or argon2in 48 of 648, across 35 files
  • apply rate limiting to authentication endpointsin 48 of 648, across 24 files
  • Configure security headersin 35 of 648, across 18 files
  • validate all inputsin 32 of 648, across 24 files
  • validate all external input at the system boundaryin 29 of 648, across 18 files
  • run containers as a non-root userin 28 of 648, across 15 files
  • use httponly secure samesite cookies for sessionsin 26 of 648, across 15 files
  • run dependency audits before every releasein 21 of 648, across 10 files
  • encode output to prevent cross-site scriptingin 21 of 648, across 10 files
  • copy dependencies before source codein 20 of 648, across 9 files
  • store secrets in environment variablesin 20 of 648, across 17 files

Said here and by no other author read

  • send full error details only to internal logs
  • validate incoming data in every controller or route handler
  • whitelist fields explicitly to prevent mass assignment
  • apply rate limits to sensitive operations
  • restrict log file access

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

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.