agentsclimarketplace

Security checklist

Skill atuljha23/holocron/skills/security-checklist

OWASP-style quick reference — authn/authz, injection, secrets, sessions, crypto, dependencies. Use during code review and before committing security-sensitive changes.From its SKILL.md

Install
npx -y skills add atuljha23/holocron --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

  • 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.

SKILL.md

3.7 KB, 900 tokens by cl100k_base, as published. Nobody here has run it

Security checklist

Authn / authz

  • Authentication check happens on a path the caller can't influence (verified JWT, session cookie with HttpOnly/Secure/SameSite).
  • Authorization is explicit in the handler, not implied by routing.
  • Role/permission decisions use the server's identity model, never a client-supplied header.
  • Multi-tenant check: the resource belongs to the caller's tenant (not just the caller's user).
  • No IDOR: object IDs in URLs are checked against ownership, not just existence.

Input validation

  • Validated at the edge (handler/controller), not deep in services.
  • Schema-based where possible (zod/pydantic/struct tags).
  • Every sink is aware of the shape feeding it (SQL parameters, shell args, template context, file paths, HTTP URLs, deserializers).

Injection surfaces

  • SQL: parameters only. Never string-concat into a query.
  • Shell: use argv arrays, never exec(string) with user input. Use a safe runner (execFile, subprocess.run([...])).
  • Path: reject .., absolute paths, and symlinks that escape the allowed root.
  • Template: auto-escape on; avoid raw/|safe; parameterize over string assembly.
  • Deserializers: never pickle/yaml.load/eval on untrusted input.
  • HTML rendering: sanitize + use a framework that auto-escapes; beware dangerouslySetInnerHTML.

Secrets

  • Not in source.
  • Not logged. Scrub before logging (redact keys like password, token, secret, auth).
  • Read from env or a secrets manager.
  • Rotated when in doubt.

Sessions / cookies

  • HttpOnly, Secure, SameSite=Lax (or Strict when tighter is fine).
  • Session rotates on privilege change (login, logout, role change).
  • Logout invalidates server-side, not just client-side.

Crypto

  • Use the platform library. Never roll your own.
  • MD5 / SHA-1 are NOT for security. Use SHA-256+, bcrypt/argon2 for passwords.
  • Encryption in authenticated mode (AES-GCM), never ECB.
  • RNG: cryptographic (crypto.randomBytes / secrets.token_*), never Math.random.
  • Secrets compared in constant time where applicable.

Transport

  • TLS everywhere. Redirect HTTP → HTTPS.
  • HSTS set for production domains.
  • No secrets in query strings (URLs end up in logs).
  • CSRF: token on state-changing endpoints (unless using strict CORS + SameSite cookies and you can prove it).

CORS

  • Allow-list, not wildcard, for credentialed requests.
  • Access-Control-Allow-Origin: * never with Access-Control-Allow-Credentials: true.

Output / response

  • Return only fields the caller is entitled to — no "send the whole ORM object" leaks.
  • Error messages don't expose internals (stack traces, SQL, file paths) to clients.

Dependencies

  • npm audit / pip-audit / bundler-audit / cargo audit / govulncheck clean (or triaged).
  • New dep has a real reason. Not "saw it on a blog post."

Rate limiting / abuse

  • Expensive endpoints throttled per user/IP/tenant.
  • Login is bruteforce-protected (rate limit + lockout threshold).
  • Enumeration-resistant responses on auth endpoints.

File uploads

  • Type detected from content, not extension.
  • Size limits enforced before reading into memory.
  • Served from a domain without session cookies (or via signed URL).

Logging

  • No PII / secrets in logs.
  • Log authn events (success, failure, logout).
  • Include requestId for correlation.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most security skills give in 900 tokens

Counted across 666 of the 889 authors here whose files we hold, read 2026-09-06

  • Use parameterized queries for database accesshere, and in 82 of 666, across 79 files
  • Hash passwords with BCryptin 55 of 666, across 39 files
  • Implement rate limiting for public endpointsin 48 of 666, across 34 files
  • Use environment variables for secretsin 35 of 666
  • Scan dependencies for vulnerabilitiesin 35 of 666, across 24 files
  • Validate and sanitize all user inputin 35 of 666, across 32 files
  • Add security headers to all responsesin 34 of 666, across 20 files
  • Validate all external input at the system boundaryin 26 of 666, across 25 files
  • Use parameterized queries to prevent SQL injectionin 25 of 666, across 13 files
  • Store secrets in Vault or environment variablesin 25 of 666, across 10 files
  • Run containers as a non-root userin 21 of 666, across 18 files
  • Validate all input using Bean Validationin 19 of 666, across 5 files

Said here and by no other author read

  • Verify authentication on paths caller cannot influence
  • Perform authorization checks explicitly in the handler
  • Validate input at the edge using schemas
  • Use argv arrays for shell commands
  • Rotate sessions on privilege changes
  • Use platform libraries for cryptographic operations

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. 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.