agentsclimarketplace

Security checklist

Skill sefaertunc/Worclaude/.claude/skills/security-checklist

CLI scaffolding tool that generates tailored .claude/ workflow infrastructure for Claude Code projects

Install
npx -y skills add sefaertunc/Worclaude --skill security-checklist

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

One thing to look at

  • 4 stars4 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

OWASP-based security checklist any agent can reference when reviewing or writing code

SKILL.md

4.7 KB, as published. Nobody here has run it

Security Checklist

Purpose

This is a reference checklist, not an agent. Any agent — code-simplifier, test-writer, verify-app, or the main session — can consult this when they encounter security-relevant code. The dedicated security-reviewer agent does deeper analysis; this checklist catches the obvious issues.

Quick Scan (30 seconds)

Before committing any code that handles user input, authentication, or external data, check these five things:

  1. No hardcoded secrets — grep for API keys, passwords, tokens, connection strings
  2. Input is validated — user input goes through validation before use
  3. Queries are parameterized — no string concatenation in SQL/NoSQL queries
  4. Output is escaped — user content is not rendered as raw HTML
  5. Auth is checked — protected endpoints have authentication middleware

If any fail, stop and fix before committing.

OWASP Top 10 Reference

A01: Broken Access Control

  • Every endpoint checks authentication AND authorization
  • Users cannot access other users' resources by changing IDs in URLs
  • File paths from user input are sanitized (no path traversal)
  • CORS is configured to allow only expected origins
  • Directory listing is disabled on static file servers

A02: Cryptographic Failures

  • Passwords hashed with bcrypt, scrypt, or argon2 — never MD5/SHA for passwords
  • Sensitive data encrypted at rest (PII, payment info)
  • HTTPS enforced in production — no mixed content
  • API keys and secrets stored in environment variables, not source code
  • Random values use crypto-secure generators, not Math.random()

A03: Injection

  • SQL: parameterized queries or ORM — never string concatenation
  • NoSQL: no user input in $where, $regex operators
  • OS commands: use dedicated libraries, not shell execution with user input
  • LDAP: parameterized queries if applicable
  • Template engines: auto-escaping enabled by default

A04: Insecure Design

  • Rate limiting on authentication endpoints
  • Account lockout after repeated failures
  • No sensitive data in URLs or query parameters
  • Session tokens regenerated after login
  • Passwords have minimum complexity requirements

A05: Security Misconfiguration

  • Debug mode disabled in production
  • Default credentials changed
  • Security headers set: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security
  • Error messages don't expose stack traces or internal details to users
  • Unused features and endpoints removed

A06: Vulnerable Components

  • Dependencies up to date — no known CVEs
  • Lock files committed (package-lock.json, yarn.lock, etc.)
  • Dependency audit clean: npm audit, pip audit, cargo audit
  • No abandoned packages with no maintenance

A07: Authentication Failures

  • Passwords not stored in plaintext
  • JWT tokens validated on every request (signature, expiry, issuer)
  • Session management uses secure cookies (HttpOnly, Secure, SameSite)
  • Password reset tokens are single-use and time-limited
  • Multi-factor authentication available for sensitive operations

A08: Data Integrity Failures

  • Deserialization of user input uses safe libraries
  • CI/CD pipelines verify integrity of dependencies
  • Software updates use signed packages

A09: Logging Failures

  • Security events are logged (login attempts, access denied, input validation failures)
  • Logs do NOT contain passwords, tokens, or PII
  • Log injection is prevented (user input in logs is sanitized)
  • Alerts configured for suspicious patterns

A10: Server-Side Request Forgery (SSRF)

  • URLs from user input are validated against an allowlist
  • Internal network addresses blocked (127.0.0.1, 10.x, 169.254.x, etc.)
  • DNS rebinding protection if URL resolution is involved
  • Response from fetched URLs is not returned raw to the user

When to Consult This

  • Writing code that handles user input
  • Implementing authentication or authorization
  • Adding new API endpoints
  • Handling file uploads
  • Integrating with external services
  • Updating dependencies
  • Before any release

Common False Positives

Not everything is a security issue:

  • Test credentials in test files (clearly marked as test-only)
  • Public API keys that are designed to be public (e.g., Stripe publishable key)
  • SHA-256/MD5 used for checksums or cache keys (not for password hashing)
  • Environment variables in .env.example (templates, not real secrets)
  • Self-signed certificates in development environments

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.